lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2037) Allow Junit4 tests in our environment.
Date Sun, 29 Nov 2009 18:20:20 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783442#action_12783442
] 

Erick Erickson commented on LUCENE-2037:
----------------------------------------

Darn it! I'll get the comments right sometime and not have to retype them after making an
attachment....

Anyway, this patch allows us to use Junit4 constructs as well as Junit3 constructs. It includes
a sibling class to LuceneTestCase called LuceneTestCaseJ4 that provides the functionality
we used to get from LuceneTestCase.

When creating Junit4-style tests, preferentially import from org.junit rather than from junit.framework.

Junit-3.8.2.jar may (should?) be removed from the distro, all tests run just fine under Junit-4.7,jar,
which is attached to this issue. I wrote a little script that compares the results of running
the tests and we run exactly the same number of TestSuites and each runs exactly the same
number of tests, so I'm pretty confident about this one. I may be wrong, but I'm not uncertain.
Single data-points aren't worth much, but on my Macbook Pro, running under Junit4 took about
a minute longer than Junit3 (about 23 1/2 minutes). Which could have been the result of my
Time Machine running for all I know....

All the tests in test...search.function have been converted to use LuceneTestCaseJ4 as an
exemplar. I've deprecated LuceneTestCase to prompt people. When you derive from LuceneTestCaseJ4,
you *must* use the @Before, @After and @Test annotations to get the functionality you expect,
as must *all* subclasses. So one gotcha people will surely run across is deriving form J4
and failing to put @Test.... 

Converting all the tests was my way of working through the derivation issues. I don't particularly
see the value in doing a massive conversion just for the heck of it. Unless someone has a
real urge. More along the lines of "I'm in this test anyway, lets upgrade it and add new ones".

What about new tests? Should we encourage new patches to use Junit4 rather than Junit3? If
so, how?

I've noticed the convention of putting underscores in front of some tests to keep them from
running. The Junit4 convention is the @Ignore annotation, which will cause the @Ignored tests
to be reported (something like 1300 successful, 0 failures, 23 ignored), which is a nice way
to keep these from getting lost in the shuffle.

When this gets applied, I can put up the patch for LocalizedTestCase and we can give that
a whirl....


> Allow Junit4 tests in our environment.
> --------------------------------------
>
>                 Key: LUCENE-2037
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2037
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Other
>    Affects Versions: 3.1
>         Environment: Development
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Minor
>             Fix For: 3.1
>
>         Attachments: junit-4.7.jar, LUCENE-2037.patch, LUCENE-2037.patch
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> Now that we're dropping Java 1.4 compatibility for 3.0, we can incorporate Junit4 in
testing. Junit3 and junit4 tests can coexist, so no tests should have to be rewritten. We
should start this for the 3.1 release so we can get a clean 3.0 out smoothly.
> It's probably worthwhile to convert a small set of tests as an exemplar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message