lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: Junit4
Date Fri, 06 Nov 2009 00:57:21 GMT
OK, done, see LUCENE-2037. This makes sense if for no other reason than not
putting too many irons in the fire, especially non-critical ones. I don't
see a way to assign it to myself, either I'm missing something or I'm just
underprivileged <G>, so if someone would go ahead and assign it to me I'll
work on it post 3.0.

Erick

On Thu, Nov 5, 2009 at 7:09 PM, Uwe Schindler <uwe@thetaphi.de> wrote:

>  Hi Erick,
>
>
>
> We can switch to JUnit4 some time soon, but not before 3.0. 3.0 has no new
> features, only no deprecations anymore and Java 5 support + Generics. So all
> test stay almost the same (some minor tweaks because of deprecations). So we
> should release as soon as possible.
>
>
>
> After that we can think about switching. Open an issue in JIRA and we can
> work on it for 3.1 when flexible indexing comes in and needs new test cases.
>
>
>
> Uwe
>
>
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>   ------------------------------
>
> *From:* Erick Erickson [mailto:erickerickson@gmail.com]
> *Sent:* Thursday, November 05, 2009 11:50 AM
>
> *To:* java-dev@lucene.apache.org
> *Subject:* Re: Junit4
>
>
>
> I'm *not *advocating converting *any* tests just to incorporate Junit4.
> I'm advocating doing a minimal amount of work to be able to use either, as
> we find convenient. The only restriction would be that your particular test
> class would have to use one or the other (with the caveat that derived
> subclasses would have to be consistent too).
>
>
>
> There are some features of Junit4 that I find useful, particularly things
> like @BeforeClass and @AfterClass, Expected exceptions. @Ignore (for those
> rare cases where we want to turn off a test temporarily), not having to
> derive from TestCase, timing out.  Sure, you can do all of them with Junit3,
> but you can also do anything you do in Java with assembler....
>
>
>
> Here is a page to a list of some Junit4 features if you want to browse
> them. It's not very well laid out, see the links near the bottom for
> "related posts" for equally short introductions to the other features than
> the single one at this link.
>
>
>
> http://www.mkyong.com/unittest/junit-4-tutorial-1-basic-usage/
>
>
>
> Believe me, I'm allergic to rewriting a bunch of working code just to be
> modern. But that's not what I'm thinking here at all. My only purpose in
> refactoring the tests I did to run with Junit4 was to get to the point of
> being able to say "this is possible" quickly. The choice of upgrading a
> particular junit3 test to junit4 would be strictly ad-hoc. Meanwhile, all
> the Junit3 tests would continue to run as-is and any new (or upgraded from
> Junit3 tests) would run as well as Junit4.
>
>
>
> Although there's certainly a question of whether the gotchas we'd run into
> would be worth it. I don't know of any off the top of my head, but there are
> *always* gremlins.....
>
>
>
> Best
>
> Erick
>
> On Thu, Nov 5, 2009 at 1:49 PM, Uwe Schindler <uwe@thetaphi.de> wrote:
>
> We will release Lucene 3.0 very short after 2.9.1, which will be released
> in a few days. Lucene 3.0 is already almost finished (only some small Java 5
> refactorings like varargs), but there is currently no need to rewrite the
> tests for 3.0. JUnit is working perfectly at the moment, in my opinion there
> is no need to convert all tests! There are more special testcase base
> classes in Lucene that need special handling, e.g. BaseTokenStreamTestCase
> (which tested TokenStreams with both old and new API in 2.9 and also
> provides asserts for TS contents), LocalizedTestCase (which tests in all
> Locales available, which is important for some analyzers or the
> QueryParser). These classes override runBare() to loop over the different
> Locales and so on. So lot’s of hard work.
>
>
>
> I would suggest to leave all test as they are, is there any important
> feature in JUnit 4 we could use?
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>   ------------------------------
>
> *From:* Erick Erickson [mailto:erickerickson@gmail.com]
> *Sent:* Thursday, November 05, 2009 10:24 AM
> *To:* java-dev@lucene.apache.org
> *Subject:* Re: Junit4
>
>
>
> One other thing I thought of last night: Are there any objections to
> deprecating LuceneTestCase? I know we're trying to avoid deprecating things
> in 3.0, but since this isn't user-facing it seems reasonable. If it's
> deprecated, it'll at least give test writers a hint that junit4 is available
> (I'll include some pointers in the javadocs...)...
>
>
>
> Erick
>
> On Wed, Nov 4, 2009 at 9:07 PM, Erick Erickson <erickerickson@gmail.com>
> wrote:
>
> Now that we're going for Java 5, I took some time this evening to poke at
> using Junit4. I've done enough for proof of concept (POC), but before going
> further I wondered if there's enough interest or cautions or objections.
>
> It's actually not bad. I was afraid that we'd have to do an "all or none"
> conversion, but Junit3 and Junit4 co-exist quite happily both in IntelliJ
> and in ant.
>
> I managed to get all of the tests in
> ...test/org/apache/lucene/search/function to run under junit4, while all the
> rest of the tests are running under Junit3....
>
> The short form is that I made a copy of LuceneTestCase called
> LuceneTestCaseJ4 that does NOT derive from TestCase but preserves (almost)
> all of the other functionality. There's some pesky nonsense with the
> constructor that takes a parameter (apparently disallowed by Junit4, and for
> POC I'm not going to worry about it, I'm not sure this is anything more than
> an artifact of Junit3 and can be removed). From there, it was just a matter
> of making the relevant test cases inherit from LuceneTestCaseJ4 and
> resolving some visibility issues (e.g. the setup and teardown (i.e. @Before
> and @After) in LTCJ4 had to be public), and resolving imports.
>
> I had to hack the common-build.xml a bit (warning, I'm no Ant expert) to
> include both junit jars, but that seems to work fine.
>
> So I *claim* that we can gradually migrate to junit4 if we want to without
> having to do a massive migration. I really haven't looked very carefully at
> the base LuceneTestCase class, but I can successfully comingle Junit3 and
> Junit4 testcases so I thought it was worth discussing. Note that I didn't do
> *anything* except get the tests to run. That is, other than adding things
> like @Before and @After and @Test, I didn't take advantage of any of the
> Junit4 features.
>
> If there's enough interest, I'll clean some things up, make  a JIRA (I
> don't see anything in there already on this topic) and submit a patch in the
> next week. And this is *really* something I'd like someone else's eyes
> on....
>
> Best
> Erick
>
>
>
>
>

Mime
View raw message