Hani, > 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. Cheers, Mike. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
