lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Uwe's question
Date Fri, 26 Feb 2010 01:52:12 GMT
<<By the way, why does LuceneTestCaseJ4 extend TestWatchman and also a
instance field extends that class?>>
No good reason, I plead confusion when figuring out how to use it. I've
attached a patch to Lucene 2037 that removes the LuceneTestCaseJ4 extending

<<I do not understand the whole magic behind, this is totally confusing to
me – annotating a field that is never used in code by an annotation is
stupid and looks totally incorrect (I mean the field holding the

Well, this is to provide the same functionality as LuceneTestCase. I'm
reaching a bit here since I haven't been in that code lately, but...

LocalizedTestCase called runBare in LuceneTestCase which reported the seed
value if an exception was thrown. I couldn't find a good way to access
runBare or analogs in Junit4, but the interceptor pattern worked as well.
The interceptor is called by the Junit framework on test events, so there
aren't references to it in the Lucene test code. There are other places that
call runBare, so I assumed that if anyone wanted to use Junit4 with those
classes it would be a good thing to allow.

I think the interceptor pattern is an elegant way to "do something" at
discrete points in the test run, although it is a bit opaque.

Most of this was put in when I was trying to move LocalizedTestCase to the
Junit4 world. We didn't do that, but this still needs to be kept if we want
LuceneTestCaseJ4 to be a drop-in replacement for LuceneTestCase.

<<< - This is another thing why I am against the migration of our already
proven tests.>>>

If you'll recall the discussion at the time, neither am I. I do believe,
though, that if anyone wants to change a test class to use Junit4 it's a
good thing to have something that'll drop in without surprises, which is
what I was trying for.


View raw message