You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Varun Thacker <va...@vthacker.in> on 2018/10/24 00:39:08 UTC
Test Harness behaviour on a package run
I wanted to run all tests within one package so I ran it like this
ant clean test "-Dtests.class=org.apache.solr.search.facet.*"
The test run fails because the harness is trying to run DebugAgg as it's a
public class while it's not really a test class.
[junit4] Tests with failures [seed: EB7B560286FA14D0]:
[junit4] - org.apache.solr.search.facet.DebugAgg.initializationError
[junit4] - org.apache.solr.search.facet.DebugAgg.initializationError
Is there a way to avoid this?
Re: Test Harness behaviour on a package run
Posted by Mark Miller <ma...@gmail.com>.
+1.
Would be great if precommit enforced a standard - both in the same package
makes sorting/browsing weird. We should also enforce that classes under
test that are not tests don't match that pattern.
- Mark
On Thu, Oct 25, 2018 at 10:04 AM David Smiley <da...@gmail.com>
wrote:
> +1 to standardize test class naming!
>
> On Thu, Oct 25, 2018 at 10:32 AM Gus Heck <gu...@gmail.com> wrote:
>
>> Or we could corral the naming of our tests into one pattern...
>>
>> On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker <va...@vthacker.in> wrote:
>>
>>> Thanks Steve! That worked for me
>>>
>>> I'll go ahrad and make this as the default example to the "test-help"
>>> target
>>>
>>> - [help] ant test "-Dtests.class=org.apache.lucene.package.*"
>>> + [help] ant test
>>> "-Dtests.class=org.apache.lucene.package.Test*|org.apache.lucene.package.*Test"
>>>
>>> On Wed, Oct 24, 2018 at 7:20 AM Steve Rowe <sa...@gmail.com> wrote:
>>>
>>>> This worked for me:
>>>>
>>>> ant clean test
>>>> "-Dtests.class=org.apache.solr.search.facet.Test*|org.apache.solr.search.facet.*Test"
>>>>
>>>> --
>>>> Steve
>>>> www.lucidworks.com
>>>>
>>>> > On Oct 24, 2018, at 3:20 AM, Dawid Weiss <da...@gmail.com>
>>>> wrote:
>>>> >
>>>> > There is no way for the runner to tell which class is a JUnit test
>>>> > class. Typically this is done with pattern matching on file names.
>>>> > common-build.xml converts this property to an file inclusion pattern
>>>> > (see tests.explicitclass) and if you include everything, the runner
>>>> > tries to load and inspect a class it knows nothing about... in fact I
>>>> > don't know why it's doing it because the runner itself has a "class
>>>> > name filter" it applies to classes before it initializes them -- the
>>>> > tests.class property should be passed directly to <junit4> task
>>>> > (instead, an empty string is passed there). Perhaps this was done to
>>>> > minimize the number of scanned/ loaded files, but it's not the best
>>>> > idea.
>>>> >
>>>> > Dawid
>>>> > On Wed, Oct 24, 2018 at 2:39 AM Varun Thacker <va...@vthacker.in>
>>>> wrote:
>>>> >>
>>>> >> I wanted to run all tests within one package so I ran it like this
>>>> >>
>>>> >> ant clean test "-Dtests.class=org.apache.solr.search.facet.*"
>>>> >>
>>>> >> The test run fails because the harness is trying to run DebugAgg as
>>>> it's a public class while it's not really a test class.
>>>> >>
>>>> >> [junit4] Tests with failures [seed: EB7B560286FA14D0]:
>>>> >> [junit4] -
>>>> org.apache.solr.search.facet.DebugAgg.initializationError
>>>> >> [junit4] -
>>>> org.apache.solr.search.facet.DebugAgg.initializationError
>>>> >>
>>>> >>
>>>> >> Is there a way to avoid this?
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>
>> --
>> http://www.the111shift.com
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
--
- Mark
about.me/markrmiller
Re: Test Harness behaviour on a package run
Posted by David Smiley <da...@gmail.com>.
+1 to standardize test class naming!
On Thu, Oct 25, 2018 at 10:32 AM Gus Heck <gu...@gmail.com> wrote:
> Or we could corral the naming of our tests into one pattern...
>
> On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker <va...@vthacker.in> wrote:
>
>> Thanks Steve! That worked for me
>>
>> I'll go ahrad and make this as the default example to the "test-help"
>> target
>>
>> - [help] ant test "-Dtests.class=org.apache.lucene.package.*"
>> + [help] ant test
>> "-Dtests.class=org.apache.lucene.package.Test*|org.apache.lucene.package.*Test"
>>
>> On Wed, Oct 24, 2018 at 7:20 AM Steve Rowe <sa...@gmail.com> wrote:
>>
>>> This worked for me:
>>>
>>> ant clean test
>>> "-Dtests.class=org.apache.solr.search.facet.Test*|org.apache.solr.search.facet.*Test"
>>>
>>> --
>>> Steve
>>> www.lucidworks.com
>>>
>>> > On Oct 24, 2018, at 3:20 AM, Dawid Weiss <da...@gmail.com>
>>> wrote:
>>> >
>>> > There is no way for the runner to tell which class is a JUnit test
>>> > class. Typically this is done with pattern matching on file names.
>>> > common-build.xml converts this property to an file inclusion pattern
>>> > (see tests.explicitclass) and if you include everything, the runner
>>> > tries to load and inspect a class it knows nothing about... in fact I
>>> > don't know why it's doing it because the runner itself has a "class
>>> > name filter" it applies to classes before it initializes them -- the
>>> > tests.class property should be passed directly to <junit4> task
>>> > (instead, an empty string is passed there). Perhaps this was done to
>>> > minimize the number of scanned/ loaded files, but it's not the best
>>> > idea.
>>> >
>>> > Dawid
>>> > On Wed, Oct 24, 2018 at 2:39 AM Varun Thacker <va...@vthacker.in>
>>> wrote:
>>> >>
>>> >> I wanted to run all tests within one package so I ran it like this
>>> >>
>>> >> ant clean test "-Dtests.class=org.apache.solr.search.facet.*"
>>> >>
>>> >> The test run fails because the harness is trying to run DebugAgg as
>>> it's a public class while it's not really a test class.
>>> >>
>>> >> [junit4] Tests with failures [seed: EB7B560286FA14D0]:
>>> >> [junit4] -
>>> org.apache.solr.search.facet.DebugAgg.initializationError
>>> >> [junit4] -
>>> org.apache.solr.search.facet.DebugAgg.initializationError
>>> >>
>>> >>
>>> >> Is there a way to avoid this?
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>
> --
> http://www.the111shift.com
>
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com
Re: Test Harness behaviour on a package run
Posted by Gus Heck <gu...@gmail.com>.
Or we could corral the naming of our tests into one pattern...
On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker <va...@vthacker.in> wrote:
> Thanks Steve! That worked for me
>
> I'll go ahrad and make this as the default example to the "test-help"
> target
>
> - [help] ant test "-Dtests.class=org.apache.lucene.package.*"
> + [help] ant test
> "-Dtests.class=org.apache.lucene.package.Test*|org.apache.lucene.package.*Test"
>
> On Wed, Oct 24, 2018 at 7:20 AM Steve Rowe <sa...@gmail.com> wrote:
>
>> This worked for me:
>>
>> ant clean test
>> "-Dtests.class=org.apache.solr.search.facet.Test*|org.apache.solr.search.facet.*Test"
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On Oct 24, 2018, at 3:20 AM, Dawid Weiss <da...@gmail.com> wrote:
>> >
>> > There is no way for the runner to tell which class is a JUnit test
>> > class. Typically this is done with pattern matching on file names.
>> > common-build.xml converts this property to an file inclusion pattern
>> > (see tests.explicitclass) and if you include everything, the runner
>> > tries to load and inspect a class it knows nothing about... in fact I
>> > don't know why it's doing it because the runner itself has a "class
>> > name filter" it applies to classes before it initializes them -- the
>> > tests.class property should be passed directly to <junit4> task
>> > (instead, an empty string is passed there). Perhaps this was done to
>> > minimize the number of scanned/ loaded files, but it's not the best
>> > idea.
>> >
>> > Dawid
>> > On Wed, Oct 24, 2018 at 2:39 AM Varun Thacker <va...@vthacker.in>
>> wrote:
>> >>
>> >> I wanted to run all tests within one package so I ran it like this
>> >>
>> >> ant clean test "-Dtests.class=org.apache.solr.search.facet.*"
>> >>
>> >> The test run fails because the harness is trying to run DebugAgg as
>> it's a public class while it's not really a test class.
>> >>
>> >> [junit4] Tests with failures [seed: EB7B560286FA14D0]:
>> >> [junit4] -
>> org.apache.solr.search.facet.DebugAgg.initializationError
>> >> [junit4] -
>> org.apache.solr.search.facet.DebugAgg.initializationError
>> >>
>> >>
>> >> Is there a way to avoid this?
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
--
http://www.the111shift.com
Re: Test Harness behaviour on a package run
Posted by Varun Thacker <va...@vthacker.in>.
Thanks Steve! That worked for me
I'll go ahrad and make this as the default example to the "test-help" target
- [help] ant test "-Dtests.class=org.apache.lucene.package.*"
+ [help] ant test
"-Dtests.class=org.apache.lucene.package.Test*|org.apache.lucene.package.*Test"
On Wed, Oct 24, 2018 at 7:20 AM Steve Rowe <sa...@gmail.com> wrote:
> This worked for me:
>
> ant clean test
> "-Dtests.class=org.apache.solr.search.facet.Test*|org.apache.solr.search.facet.*Test"
>
> --
> Steve
> www.lucidworks.com
>
> > On Oct 24, 2018, at 3:20 AM, Dawid Weiss <da...@gmail.com> wrote:
> >
> > There is no way for the runner to tell which class is a JUnit test
> > class. Typically this is done with pattern matching on file names.
> > common-build.xml converts this property to an file inclusion pattern
> > (see tests.explicitclass) and if you include everything, the runner
> > tries to load and inspect a class it knows nothing about... in fact I
> > don't know why it's doing it because the runner itself has a "class
> > name filter" it applies to classes before it initializes them -- the
> > tests.class property should be passed directly to <junit4> task
> > (instead, an empty string is passed there). Perhaps this was done to
> > minimize the number of scanned/ loaded files, but it's not the best
> > idea.
> >
> > Dawid
> > On Wed, Oct 24, 2018 at 2:39 AM Varun Thacker <va...@vthacker.in> wrote:
> >>
> >> I wanted to run all tests within one package so I ran it like this
> >>
> >> ant clean test "-Dtests.class=org.apache.solr.search.facet.*"
> >>
> >> The test run fails because the harness is trying to run DebugAgg as
> it's a public class while it's not really a test class.
> >>
> >> [junit4] Tests with failures [seed: EB7B560286FA14D0]:
> >> [junit4] - org.apache.solr.search.facet.DebugAgg.initializationError
> >> [junit4] - org.apache.solr.search.facet.DebugAgg.initializationError
> >>
> >>
> >> Is there a way to avoid this?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Test Harness behaviour on a package run
Posted by Steve Rowe <sa...@gmail.com>.
This worked for me:
ant clean test "-Dtests.class=org.apache.solr.search.facet.Test*|org.apache.solr.search.facet.*Test"
--
Steve
www.lucidworks.com
> On Oct 24, 2018, at 3:20 AM, Dawid Weiss <da...@gmail.com> wrote:
>
> There is no way for the runner to tell which class is a JUnit test
> class. Typically this is done with pattern matching on file names.
> common-build.xml converts this property to an file inclusion pattern
> (see tests.explicitclass) and if you include everything, the runner
> tries to load and inspect a class it knows nothing about... in fact I
> don't know why it's doing it because the runner itself has a "class
> name filter" it applies to classes before it initializes them -- the
> tests.class property should be passed directly to <junit4> task
> (instead, an empty string is passed there). Perhaps this was done to
> minimize the number of scanned/ loaded files, but it's not the best
> idea.
>
> Dawid
> On Wed, Oct 24, 2018 at 2:39 AM Varun Thacker <va...@vthacker.in> wrote:
>>
>> I wanted to run all tests within one package so I ran it like this
>>
>> ant clean test "-Dtests.class=org.apache.solr.search.facet.*"
>>
>> The test run fails because the harness is trying to run DebugAgg as it's a public class while it's not really a test class.
>>
>> [junit4] Tests with failures [seed: EB7B560286FA14D0]:
>> [junit4] - org.apache.solr.search.facet.DebugAgg.initializationError
>> [junit4] - org.apache.solr.search.facet.DebugAgg.initializationError
>>
>>
>> Is there a way to avoid this?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Test Harness behaviour on a package run
Posted by Dawid Weiss <da...@gmail.com>.
There is no way for the runner to tell which class is a JUnit test
class. Typically this is done with pattern matching on file names.
common-build.xml converts this property to an file inclusion pattern
(see tests.explicitclass) and if you include everything, the runner
tries to load and inspect a class it knows nothing about... in fact I
don't know why it's doing it because the runner itself has a "class
name filter" it applies to classes before it initializes them -- the
tests.class property should be passed directly to <junit4> task
(instead, an empty string is passed there). Perhaps this was done to
minimize the number of scanned/ loaded files, but it's not the best
idea.
Dawid
On Wed, Oct 24, 2018 at 2:39 AM Varun Thacker <va...@vthacker.in> wrote:
>
> I wanted to run all tests within one package so I ran it like this
>
> ant clean test "-Dtests.class=org.apache.solr.search.facet.*"
>
> The test run fails because the harness is trying to run DebugAgg as it's a public class while it's not really a test class.
>
> [junit4] Tests with failures [seed: EB7B560286FA14D0]:
> [junit4] - org.apache.solr.search.facet.DebugAgg.initializationError
> [junit4] - org.apache.solr.search.facet.DebugAgg.initializationError
>
>
> Is there a way to avoid this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org