On 6/15/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
1) Modifying existing search tests to implicitly check explain
LUCENE-557-modify-existing-tests.patch modifies (almost) every core test I
could find that used an IndexSearcher to use a modified IndexSearcher that
implicitly tests explanations as well. I mainly wrote this to help me
spot the problem queries when writing new test classes, but I'm wondering
what people think about commiting this change.
It essentially boils down to this...
- Searcher searcher = new IndexSearcher(directory);
+ Searcher searcher = new CheckHits.ExplanationAssertingSearcher(directory);
...across 43 Test classes. Should those changes be committed? Part of me
says "no" because it's kind of ugly, but another part of me says "yes"
because it's the best way to ensure that as fuctionality evolves, future
committers will be alerted if they cahnge the search behavior of query
without making corrisponding hanges to the explain behavior.
Just brainstorming, but what would be cool is if we had a generic way
to insert extra checks/functionality in searcher.
- maybe an IndexSearcher factory that would at least allow a
different implementation to be run with the testsuite.
- maybe a place to register your IndexSearcher callbacks (would
allow multiple checks in a single test run).
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
