lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: [subscriptions] Re: Please make org.apache.lucene.index.IndexWriter non-final
Date Sun, 05 Oct 2003 18:52:03 GMT
On Sunday, October 5, 2003, at 10:39  AM, Mike Hogan wrote:
> 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:
> 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.


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

View raw message