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 ;)
Hani
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:
http://lists.codehaus.org/pipermail/picocontainer-dev/2003-July/ 000743.html,
so am interested to see what value you get from final.
Cheers, Mike.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
