lucene-dev mailing list archives

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

I think your design is the one we need to call into question here.  If 
you have a few simple API calls (your own, that is, the search one you 
showed before), then your design should accommodate the mock situation 
you're grasping for here.  Again, how about a SearchManager interface, 
and then a LuceneSearchManager implementation, then a MockSearchManager 
interface that you can send into your higher level methods to see what 
happens without actually calling Lucene at all?  Or perhaps a 
DirectoryFactory that is used to construct either a RAMDirectory (for 
testing) or FSDirectory (for production)?

>> 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 disagree here.  A mock *is* supposed to work.  Its the Real Deal, but 
with some reporting capabilities added on so you can see what happens 
to it as it goes through a black box.  We need to know precisely what 
we are testing here to really say whether a particular use of mocks is 
bad or good, but I'm sitting between Mike and Hani here.... mocks are 
great, but must be focused on one layer to test, not more.  Mocks can 
be abused, and this I feel is Mike's situation.  Mike.... refactor and 
redesign - don't try to change Lucene to make your testing easier - 
what you're after can be done without touching Lucene.  Besides, we 
won't let you touch Lucene that way anyway :))

	Erik


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