lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Hogan" ...@mikehogan.net>
Subject Re: [subscriptions] Re: Please make org.apache.lucene.index.IndexWriter non-final
Date Sun, 05 Oct 2003 21:05:32 GMT
Erik,

> 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.

A few posts back I pasted the refactored design I had when I tried to
mock-test my code.  You are right to say my code needs refactoring to unit
test.  I just rolled it back to the untestable state once I ran into the
public final IndexWriter problem.

> I would even go so far as to argue that RAMDirectory is a mock object
> (albeit a very sophisticated one) of sorts.

Yes it is.  But its too sophisticated for what I need.  I can do the same
with a small test case and two small mocks.  My preference only.  Hence this
email thread.

> 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.

Well, this is a side issue and I probably should not have started it, but
I've started so I might as well continue :-).  What is the benefit of final
on a class?  Are you concerned that somebody will subclass an IndexWriter
and shag things up?  If so, shag _them_!

Cheers,
Mike.


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message