[jira] Created: (LUCENE-2037) Allow Junit4 tests in our environment.

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
            Priority: Minor
             Fix For: 3.1


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@...
For additional commands, e-mail: java-dev-help@...

     [ https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson updated LUCENE-2037:
-----------------------------------

    Remaining Estimate: 8h  (was: 24h)
     Original Estimate: 8h  (was: 24h)

> 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
>            Priority: Minor
>             Fix For: 3.1
>
>   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@...
For additional commands, e-mail: java-dev-help@...

     [ https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man reassigned LUCENE-2037:
--------------------------------

    Assignee: Erick Erickson

It's all yours Erick.

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

     [ https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson updated LUCENE-2037:
-----------------------------------

    Attachment: junit-4.7.jar
                LUCENE-2037.patch

LuceneTestCaseJ4 should replace LuceneTestCase. There's a bit of overkill here to emulate the override of runBare in LuceneTestCase, but I thought it was worth it to work out the mechanisms.

We'll need to put the lucene 4.7 jar in the right place.

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

Uwe Schindler commented on LUCENE-2037:
---------------------------------------

One thing that would also be good:
We have LocalizedTestCase, which has the possibility to run each test for all available Locales (it overrides currently runBare() and iterates while setting Locale.setDefault()). As this test should only be ran for specific methods, how about adding a annotation in addition to @Test (with Retention("method") like @TestLocalized.

What to do with BaseTokenStreamTestCase? In 2.9 it had also overridden runBare(), but not anymore (because we only have the new TS API anymore), but this is also a typical example when we want to rerun tests multiple times. One on our plan is that this test now runs all analyzer test for different default versions (iterate over Version enum constants). We need then something like @TestAllVersions or something like that. If we jump to JUnit4, we should use the new features for a more elegant solution of these multiple-run tests.

One note: It would be good to *not* reformat the whole tests with an Eclipse cleanup, just change the lines you modified, not reformat everything or organize imports and so on. Its hard to find out what has changed.

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

[Erick Erickson]

Good suggestions, it's really helpful to have someone intimately familiar with the code suggest the next direction. I didn't want to go too far afield for the proof-of-concept, I mostly wanted to have a place to start. LuceneTestCaseJ4 should be useful both as a template and a base to build with. If you wanted to put in a  JIRA or two and assign them to me I'd be happy to take a look. I'm pushing this off on you since you have a better sense of what's important here....

About reformatting. I'm torn, for all the reasons I'm certain you can quote.  Of course I'll abide by the sense of the community, but "the community" doesn't speak with one voice. Michael McCandless and I had an exchange on this very topic and he is in the opposite camp. I guess I was heavily influenced by Martin Fowler's "Refactoring" book and the eXtreme Programming folks....

What I'd personally like would be for someone with heavy commit privileges to reformat the whole thing at once and just get it *done*, as was apparently discussed at ApacheCon. Eclipse makes this easy. I'd also like to be wealthy.... Look at the bright side, I'm not trying to convince anyone that "my way of formatting is obviously superior because I put braces on their own line" <G>....

Best
Erick

On Sun, Nov 15, 2009 at 6:16 AM, Uwe Schindler (JIRA) <jira@...> wrote:

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

Uwe Schindler commented on LUCENE-2037:
---------------------------------------

One thing that would also be good:
We have LocalizedTestCase, which has the possibility to run each test for all available Locales (it overrides currently runBare() and iterates while setting Locale.setDefault()). As this test should only be ran for specific methods, how about adding a annotation in addition to @Test (with Retention("method") like @TestLocalized.

What to do with BaseTokenStreamTestCase? In 2.9 it had also overridden runBare(), but not anymore (because we only have the new TS API anymore), but this is also a typical example when we want to rerun tests multiple times. One on our plan is that this test now runs all analyzer test for different default versions (iterate over Version enum constants). We need then something like @TestAllVersions or something like that. If we jump to JUnit4, we should use the new features for a more elegant solution of these multiple-run tests.

One note: It would be good to *not* reformat the whole tests with an Eclipse cleanup, just change the lines you modified, not reformat everything or organize imports and so on. Its hard to find out what has changed.

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

Robert Muir edited comment on LUCENE-2037 at 11/15/09 1:45 PM:
---------------------------------------------------------------

Is there some way to use Junit4 parameterized tests to do this LocalizedTestCase-type thing, so we don't have to override runBare()?


      was (Author: rcmuir):
    Is there some way to use Junit4 parameterized tests to do this LocalizedTestCase-type thing, so we don't have to override runBase()?

 

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

Robert Muir commented on LUCENE-2037:
-------------------------------------

Is there some way to use Junit4 parameterized tests to do this LocalizedTestCase-type thing, so we don't have to override runBase()?

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

[Erick Erickson]

That thought occurred to me earlier, but I don't know enough specifics yet. I intend
to find out though....

Erick

On Sun, Nov 15, 2009 at 8:46 AM, Robert Muir (JIRA) <jira@...> wrote:

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

Robert Muir edited comment on LUCENE-2037 at 11/15/09 1:45 PM:
---------------------------------------------------------------

Is there some way to use Junit4 parameterized tests to do this LocalizedTestCase-type thing, so we don't have to override runBare()?


     was (Author: rcmuir):
   Is there some way to use Junit4 parameterized tests to do this LocalizedTestCase-type thing, so we don't have to override runBase()?


> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

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

Well, it all depend on how you feel about 10 seconds as far as LocalizedTestCase is concerned.

JUnit4 is really not built to run some tests in a class with the @Parameterized notation and some not, it runs all the tests in the class with all the parameters. In the case of TestQueryParser, which is the only test class I saw that made use of the "include some tests but not others' in LocalizedTestCase, I hacked in running all the tests with all the locales available (152 in my case). Which pushes the number of tests in that one class up over 4,000 FWIW.

Running that test case went from around 5 seconds to around 15 seconds on my 2 year old Macbook Pro, from inside IntelliJ.

I don't think it's worth trying to refactor that class into two classes, one that has all the tests run with all the locales and one that has the rest of the tests run only with the default locale (which is how I read the code in LocalizedTestcase) for 10 seconds worth of time savings. One could emulate the old process of excluding some tests by returning immediately from those tests that *weren't* intended to be run with all locales if the current locale wasn't the default, but I don't see that as worth the effort, although I could be convinced otherwise if people feel strongly.

I'll provide a patch for this if there are no objections later this week, perhaps I'll get a chance to look at BaseTokenStreamTestCase before then.

This will make LocalizedTestCase obsolete and I'll remove it in the patch.

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

Robert Muir commented on LUCENE-2037:
-------------------------------------

{quote}
I don't think it's worth trying to refactor that class into two classes, one that has all the tests run with all the locales and one that has the rest of the tests run only with the default locale (which is how I read the code in LocalizedTestcase) for 10 seconds worth of time savings. One could emulate the old process of excluding some tests by returning immediately from those tests that weren't intended to be run with all locales if the current locale wasn't the default, but I don't see that as worth the effort, although I could be convinced otherwise if people feel strongly.
{quote}

Hi, the current behavior is a little silly.
I thought it would be user-friendly to run the default locale first, then all the other locales (including a duplicate run of the default locale).
This way if you broke a test, you would see failures in your native language/format rather than some very strange language.

On the other hand, by using LocalizedTestCase, you are saying 'hey i am saying this thing has locale-sensitive behavior and it better work', so in my opinion, getting rid of this 'first run tests under default locale' doesn't harm a thing.
instead, just run under all locales, or maybe sort them so the default one is first, or something else?

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

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

I was thinking more about TestQueryParser. One of the features of the
current setup is that you specify which tests in a class you want to have
run under all locales. Tests not in that list are run only under the default
locale.Always assuming I'm reading things right...

I don't see a clean way to emulate that part of the behavior without either
refactoring or introducing a test in the tests we don't want to run under
all locales and aborting early.

But I think we're finding different ways to agree here. I'm interpreting
your comments that running all the tests in the class is OK at least for
now...

But I did notice last night that a number of tests in contrib reference
LocalizedTestCase (I have two separate projects, core and contrib so it
wasn't obvious until I ran the ant task). I'll look into those tonight or
tomorrow night.

Erick

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

Robert Muir commented on LUCENE-2037:
-------------------------------------

{quote}
I was thinking more about TestQueryParser. One of the features of the
current setup is that you specify which tests in a class you want to have
run under all locales. Tests not in that list are run only under the default
locale.Always assuming I'm reading things right..
{quote}

Erick, oh I am sorry, I completely misread your comment!

This feature that allows only a subset of tests to be run "localized" where the others will be run "normally" is just a performance optimization.
all tests should (have not checked since 2.9) pass under all locales.

{quote}
But I did notice last night that a number of tests in contrib reference
LocalizedTestCase (I have two separate projects, core and contrib so it
wasn't obvious until I ran the ant task). I'll look into those tonight or
tomorrow night.
{quote}

Yes, I do feel we should keep LocalizedTestCase. It is handy, we might use it in more places to prevent test failures in other locales for new code.
But this "allowing only a subset of tests to be test in a localized way" is only a performance optimization.
If there is some test class that is really slow because all the tests are run under every locale, perhaps the locale-sensitive tests should be refactored into a separate test class that extends LocalizedTestCase.
The ones that are not locale-sensitive could be in a test class that extends LuceneTestCase

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

Uwe Schindler commented on LUCENE-2037:
---------------------------------------

I already made a propsal for LocalizedTestCase: Just mark all test to run under all Locales with a Annotation like @AllLocales.

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

Robert Muir commented on LUCENE-2037:
-------------------------------------

bq. I already made a propsal for LocalizedTestCase: Just mark all test to run under all Locales with a Annotation like @AllLocales.

looks like Parameterized supports limiting params on a per-method basis via annotation?: http://junit.org/apidocs/org/junit/runners/Parameterized.Parameters.html

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

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

I think you're mis-reading this. This is the annotation for the static
method that return a list of parameters, not for a method that is an actual
test.....

The thing that causes the framework to gather the list and run test for each
element on the list is the @RunWith annotation on the class AFAIK.

Or I'm misreading it....

Erick

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

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

Frankly, I don't see how that would work without getting into the guts of
the @RunWith(value = Parameterized.class) Junit4 annotation. As I understand
it, that annotation *on the class* causes the framework to make a call to
the static method that provides a list of parameters (annotated with
@Parameters). The framework then takes the returned list and, *for each
element in the list* calls a constructor with that element and runs all the
tests in the class.

So annotating a test with @AllLocales would somehow have to get in there and
change what the framework does. No doubt it's do-able, but until I see more
than 10 seconds difference in running the tests I'm not sure it's worth it.
Nor would I advocate altering the behavior of the framework for back-compat,
I'd far rather refactor the tests into those that run for all locales and
those that don't.

I suppose one could to the inverse, that is create an annotation
@DefaultLocaleOnly that aborts early if the locale isn't the default, but
again I think the first approach I'd advocate would be to work within the
framework until it was too painful....

FWIW
Erick

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

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

{quote}
Yes, I do feel we should keep LocalizedTestCase. It is handy, we might use
it in more places to prevent test failures in other locales for new code.
{quote}

Light went off when walking around. I think I can just change the
LocalizedTestCase class and put the @RunWith() and @Parameters *there*.
Which makes waaaaaay more sense than what I was doing which was putting
those in every subclass of the current LocalizedTestCase. Doh! I'll take a
peek tonight. Although last night I was thinking "Gee, this is
repetitive"....

There are only two classes in core that use LocalizedTestCase, but there are
several in contrib too. They'll all require the @Test annotation if I munge
LocalizedTesCase, but that should be the only change necessary then,
assuming we're content to run all the locales past all the test cases in all
derived classes.....

Hmmmm, why was subclassing invented again? Something about putting common
behavior in one place or some nonsense like that <G>.

Erick

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

Uwe Schindler commented on LUCENE-2037:
---------------------------------------

We have a second place (I did not implement this for 3.0, because no time), we need to sometimes test something for all Version enum constants. So @Parameters would return EnumSet.allOf(Version.class) and the ctor of this TestCase would get the version, and store it per instance. Tests would then run for each possible version to test compatibility.

Problem, it interferes with LoalizedTestCase, because e.g. QueryParser needs a test in all versions (n), but also in all Locales (m). Produces n x m test runs *arrrgh*. Any idea? On the other hand, TestHighlighter only needs the version iteration to test fully.

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...

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

Robert Muir commented on LUCENE-2037:
-------------------------------------

Uwe, can you elaborate more on how the Version testing would work?

do you mean the case where you have unchanged behavior across all versions, and you want to run the test against all of them, but then some tests only apply to specific versions?

bq. Problem, it interferes with LoalizedTestCase, because e.g. QueryParser needs a test in all versions , but also in all Locales (m). Produces n x m test runs arrrgh. Any idea?

at least the old tokenstream api is done, imagine if you wanted to test version, locales, and tokenstream api :)

> 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
>
>   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@...
For additional commands, e-mail: java-dev-help@...