|
Junit4
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
|
|
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@...> 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
|
|
RE: Junit4
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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?
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@...> 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
|
|
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.
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@...> 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?
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@...> 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
|
|
Re: Junit4
For most test classes it means just adding @Test before its 'public void' stuff. We can add more Junit4 stuff later, like timeouts, expected exceptions etc. It will also mean to stop extending TestCase and fix the (small number?) of tests which will be affected by it?
And if we add static imports for all asserts, nothing really changes in the code .... Uwe, even if there are tests that need some work, I'm not sure how it's related to moving to Junit4 ... can't those two tasks be done in parallel? Please correct me if I'm wrong.
Shai On Thu, Nov 5, 2009 at 9:49 PM, Erick Erickson <erickerickson@...> wrote:
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.
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@...> 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?
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@...> 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
|
|
RE: Junit4
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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
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.
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.....
Erick
On Thu, Nov 5, 2009 at 1:49 PM, Uwe Schindler <uwe@...> 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?
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@...> 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
|
|
Re: Junit4
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@...> 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
From: Erick Erickson
[mailto:erickerickson@...]
Sent: Thursday, November 05, 2009
11:50 AM
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.
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.....
Erick
On Thu, Nov 5, 2009 at 1:49 PM, Uwe Schindler <uwe@...> 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?
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@...> 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
|
|
Re: Junit4
: 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.
Jira's ACLs prevent issues from being assigned to people who aren't listed
in the "Contributors" group. THe policy has been to add people to that
list (for issue assignment) on request, so i hooked you up.
(NOTE: if anyone else has issues they're actively working on and would
like to be flagged as a "Contributor" in Jira so that the issues can be
assigned directly to you for tracking purpose, please speak up)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...
|
|
Re: Junit4
OK thanks for adding me to the ACL. I'll have it tomorrow sometime. Does anyone object to deprecating LuceneTestCase with notations to use LuceneTestCaseJ4? I tried two approaches, both work. Both allow you to use LuceneTestCaseJ4 rather than LuceneTestCase as a superclass, with the caveat you have to use the proper annotations with the J4 variant.
The difference is that for one approach, I copied LuceneTestCase to LuceneTestCaseJ4 and hacked. The other approach was extracting the meat of LuceneTestCase to a common class, and using that class as a member of both variants, delegating to avoid code duplication.
Personally, I think it'll be cleanest to just clone LuceneTestCase and NOT extract to common. Eventually LuceneTestCase will fade away, enhancements should be made to the J4 variant as needed. But if folks have strong opinions, let me know.
Best Erick On Fri, Nov 13, 2009 at 5:02 PM, Chris Hostetter <hossman_lucene@...> wrote:
: 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.
Jira's ACLs prevent issues from being assigned to people who aren't listed
in the "Contributors" group. THe policy has been to add people to that
list (for issue assignment) on request, so i hooked you up.
(NOTE: if anyone else has issues they're actively working on and would
like to be flagged as a "Contributor" in Jira so that the issues can be
assigned directly to you for tracking purpose, please speak up)
-Hoss
|
|
Re: Junit4
Well, the patch is in shape to submit, but looking at the various comments on the 3.0 release, I guess I should wait until 3.0 is actually out the door before submitting unless someone just can't wait. How do we include a new jar file in a patch?
Best Erick On Fri, Nov 13, 2009 at 6:25 PM, Erick Erickson <erickerickson@...> wrote:
OK thanks for adding me to the ACL. I'll have it tomorrow sometime. Does anyone object to deprecating LuceneTestCase with notations to use LuceneTestCaseJ4?
I tried two approaches, both work. Both allow you to use LuceneTestCaseJ4 rather than LuceneTestCase as a superclass, with the caveat you have to use the proper annotations with the J4 variant.
The difference is that for one approach, I copied LuceneTestCase to LuceneTestCaseJ4 and hacked. The other approach was extracting the meat of LuceneTestCase to a common class, and using that class as a member of both variants, delegating to avoid code duplication.
Personally, I think it'll be cleanest to just clone LuceneTestCase and NOT extract to common. Eventually LuceneTestCase will fade away, enhancements should be made to the J4 variant as needed. But if folks have strong opinions, let me know.
Best
ErickOn Fri, Nov 13, 2009 at 5:02 PM, Chris Hostetter <hossman_lucene@...> wrote:
: 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.
Jira's ACLs prevent issues from being assigned to people who aren't listed
in the "Contributors" group. THe policy has been to add people to that
list (for issue assignment) on request, so i hooked you up.
(NOTE: if anyone else has issues they're actively working on and would
like to be flagged as a "Contributor" in Jira so that the issues can be
assigned directly to you for tracking purpose, please speak up)
-Hoss
|
|
Re: Junit4
On Sun, Nov 15, 2009 at 1:19 AM, Erick Erickson < erickerickson@...> wrote:
> Well, the patch is in shape to submit, but looking at the various comments
> on the 3.0 release, I guess I should wait until 3.0 is actually out the door
> before submitting unless someone just can't wait.
You can go ahead and upload the patch to the issue no matter if 3.0 is
not released.
>
> How do we include a new jar file in a patch?
Just upload it to JIRA too.
>
> Best
> Erick
>
> On Fri, Nov 13, 2009 at 6:25 PM, Erick Erickson < erickerickson@...>
> wrote:
>>
>> OK thanks for adding me to the ACL. I'll have it tomorrow sometime. Does
>> anyone object to deprecating LuceneTestCase with notations to use
>> LuceneTestCaseJ4?
>>
>> I tried two approaches, both work. Both allow you to use LuceneTestCaseJ4
>> rather than LuceneTestCase as a superclass, with the caveat you have to use
>> the proper annotations with the J4 variant.
>>
>> The difference is that for one approach, I copied LuceneTestCase to
>> LuceneTestCaseJ4 and hacked. The other approach was extracting the meat of
>> LuceneTestCase to a common class, and using that class as a member of both
>> variants, delegating to avoid code duplication.
>>
>> Personally, I think it'll be cleanest to just clone LuceneTestCase and NOT
>> extract to common. Eventually LuceneTestCase will fade away, enhancements
>> should be made to the J4 variant as needed. But if folks have strong
>> opinions, let me know.
>>
>> Best
>> Erick
>>
>> On Fri, Nov 13, 2009 at 5:02 PM, Chris Hostetter
>> < hossman_lucene@...> wrote:
>>>
>>> : 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.
>>>
>>> Jira's ACLs prevent issues from being assigned to people who aren't
>>> listed
>>> in the "Contributors" group. THe policy has been to add people to that
>>> list (for issue assignment) on request, so i hooked you up.
>>>
>>> (NOTE: if anyone else has issues they're actively working on and would
>>> like to be flagged as a "Contributor" in Jira so that the issues can be
>>> assigned directly to you for tracking purpose, please speak up)
>>>
>>>
>>>
>>> -Hoss
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@...
>>> For additional commands, e-mail: java-dev-help@...
>>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...
|
