lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: [subscriptions] Please make org.apache.lucene.index.IndexWriter non-final
Date Sun, 05 Oct 2003 16:42:01 GMT
On Sunday, October 5, 2003, at 10:02  AM, Mike Hogan wrote:
>     public int search(final String query, int beginIndex, final int
> endIndex, final List collector) throws SearchService.Exception {
>         int numHits = 0;
>         try {
>             final Searcher searcher = new 
> IndexSearcher(INDEX_FILE_PATH);
>             final Analyzer analyzer = new StandardAnalyzer();
>             final Query q = QueryParser.parse(query, "contents", 
> analyzer);
>             final Hits hits =;
>             numHits = hits.length();
>             while (beginIndex <= endIndex && beginIndex < numHits) {
>                 final Document doc = hits.doc(beginIndex++);
>                 collector.add(doc.get("id"));
>             }
>         } catch (java.lang.Exception e) {
>             throw new SearchService.Exception("Exception performing 
> Lucene
> search",e);
>         }
>         return numHits;
>     }
> So sometimes I want QueryParser.parse() to throw an exception, 
> sometimes not
> etc etc - the usual mock stuff.

I give a hearty "second" to Hani's too much mock comments.  A mock is a 
_probe_ to send in somewhere to find out how some black box operates on 
it.  In this case, your search method is not a black box at all, and 
does not take any Lucene API's as a parameter, so there is no sense 
mocking anything in this case.  As for your QueryParser comments - you 
can instantiate a QueryParser and call the *instance* parse method on 
it if that helps.

I would highly recommend you decouple what you're doing here a bit so 
that you are not reliant on the file system deep down in your code.

It appears you are wrapping Lucene.  So, if you truly want to mock 
things for testing purposes, come up with a generic interface 
(SearchManager?!) that has the search method signature that you have 
above and all the other pieces you're wrapping.  Then create a mock 
implementation of that particular interface.

Whenever you feel the desire to change an API to accommodate testing 
you really have to reevaluate the situation.  And trust me, I'm a firm 
believer (and a learning practitioner) of Test Driven Development, so 
you don't have to convince me of the benefits.  But it does take 
reversing some thinking from time to time to resist the urge to make 
everything public and open just to test it, when that compromises the 
integrity of the underlying architecture.


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

View raw message