To be honest (and yes, this is becoming a bit OT so hit delete if you're so inclined)...
We'll indulge ourselves a bit more here before we let this thread go :)
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.
I think it really boils down to what you're trying to test. We all need to know precisely what we're trying to test because we want to focus a test precisely on a small "unit". With JDBC - if you're testing how your code interacts with the JDBC layer itself, it makes sense to use a mock to avoid testing the actual implementation of the driver as well and blurring what is being tested and what the results may mean.
I'm curious what your take of the two mocks I've recently added to Lucene's codebase is - MockFilter and MockInputStream. Both of these are for sending in to somewhere else and probing what happens to them. How else could a Real Deal (tm) work in these scenarios? And, I would argue that these two are the real deals since they merely are implementations (although certainly minimal and exploratory) of the real interfaces of Lucene.
Hmmm, time to blog ;)
I agree!
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
