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.
Again, a RAMDirectory would allow you to verify that you called the Lucene API correctly. The code you showed, though, was locked into using a file system index making it inflexible and tougher to test. Your test case could construct a RAMDirectory with some know documents indexed, then call your search method and assert it got the right ones back. Yes, this impacts your design - no question. But this is a benefit of unit test driven development - you'll end up with a better design *because* you've refactored during testing.
I would even go so far as to argue that RAMDirectory is a mock object (albeit a very sophisticated one) of sorts.
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.
I think anyone arguing that final is bad because it makes unit testing more difficult is not quite seeing the big picture. 'final' is a good thing when used appropriately. And it does not make testing any harder when using 'final' the right decision for your design. In the case of Lucene, protection access was very well thought out and it is by design. It is always up for debate, but making something easier to test is not going to be a sufficient enough reason to change it. Is there a real issue with Lucene being inflexible for extension in spots? History has proven it and things have been opened up in the past couple of releases of Lucene, but there real use cases that demanded this, not just testing.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
