lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Hogan">
Subject Re: [subscriptions] Re: Please make org.apache.lucene.index.IndexWriter non-final
Date Sun, 05 Oct 2003 15:01:51 GMT

> No matter how good your mock is, it won't be as good as a lucene
> provided and maintained implementation (RAMDirectory). Mocks in fact
> are dangerous for that very reason, they seek to emulate behaviour, and
> give you a false sense of security in the correctness of the mock.

This is true, but I enter into the relationship with mocks with my eyes
open.  If I was trying to mock-out some really complex API, with a lot of
states etc, then your criticism would be justified.  But here I am trying to
mock-out a few simple API calls, which may grow in the future, yes, but not
hugely.  Personally I am happen with the risk in this case.  If only the
classes I am trying to mock-out where non-final.....:)

> The same argument is extended to JDBC usage. I much prefer to have my
> unit tests call mckoi or some other java db that can be run inline with
> an in-memory store. it's a real world db, rather than an attempt to get
> away with the bare minimum of functionality. I've yet to come across a
> mock API that actually works as well as the real thing.

Thats the point - they are not supposed to work at all, never mind as well
as the real thing.  But I know you know that.  I agree that there is a lot
more room for error and a false sense of security when mock-testing JDBC
code.  I have been burned by that myself.  Like so much in this great
science of ours, it comes down to tradeoffs.  In the case of JDBC, its
complex enough to require Real Deal testing and mock-testing.  In this
simple case, I find mock-testing is sufficient.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message