lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hani Suleiman <>
Subject Re: [subscriptions] Re: Please make org.apache.lucene.index.IndexWriter non-final
Date Sun, 05 Oct 2003 14:50:25 GMT
To be honest (and yes, this is becoming a bit OT so hit delete if  
you're so inclined)...

I think that this shows an obsession with mocks for the sake of mocks,  
rather than any real benefit.

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.

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. To do that you  
often have to fill in all sorts of bits by hand, thus introducing the  
headache of yet more code to keep up to date and maintain, when you  
could have just used the Real Deal (tm) in the first place.

Hmmm, time to blog ;)


On Sunday, October 5, 2003, at 10:39 AM, Mike Hogan wrote:

> Erik,
>> Looks pretty much like you're testing Lucene here, not your  
>> application
>> around it.... nothing inside the try block is your own stuff its just
>> Lucene API calls.
> No, I am not testing Lucene.  I have written code that uses Lucene,  
> yes, but
> I want to _divorce_ myself from Lucene when it comes to unit testing  
> that
> code.  I just want to make sure I call the Lucene API correctly.  Not  
> by
> actually calling it in actuality, but by calling mock equivalents and
> verify()'ing that I got the correct sequence of calls.  I do not want  
> to
> have to worry about Lucene or the file system or a RAMDirectory.  This  
> is
> what mock object testing is all about, as I understand it.  Its the  
> same
> when unit testing code that does a bunch of JDBC calls.  I do not  
> actually
> want to call the real JDBC driver, I want to call a mock version and
> verify() that the parameters to my PreparedStatement and that my  
> connections
> were closed etc etc.  Involving the JDBC driver for real is an  
> integration
> test, not a unit test.
>>> What ya reckon?
>> I reckon ya oughta have a look at Lucene's test cases and source code.
>> Ever hear of RAMDirectory?!  :))
> No, I have not until now :-)  I will take a look at the Lucene test  
> cases,
> but if you are suggesting that I should slot in a file system  
> replacement to
> test my application, you're asking me to take the harder of two roads.
> Doing this makes sense for those testing Lucene itself, but not for me  
> (in
> the same way as using a database replacement makes sense for those  
> testing
> JDBC drivers).  As I said, I am concerned only with verifying that I  
> called
> the Lucene API correctly, not that Lucene does what its supposed to do  
> - I
> will test that separately.
> One final thing: what is the rationale behind using final at all on a  
> class?
> I come from this line of thinking:
> 000743.html,
> so am interested to see what value you get from final.
> Cheers,
> Mike.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message