Test Harness behaviour on a package run

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Test Harness behaviour on a package run

Varun Thacker-4
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?
Reply | Threaded
Open this post in threaded view
|

Re: Test Harness behaviour on a package run

Dawid Weiss-2
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Test Harness behaviour on a package run

sarowe
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Test Harness behaviour on a package run

Varun Thacker-4
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Test Harness behaviour on a package run

Gus Heck
Or we could corral the naming of our tests into one pattern...

On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Reply | Threaded
Open this post in threaded view
|

Re: Test Harness behaviour on a package run

david.w.smiley@gmail.com
+1 to standardize test class naming!

On Thu, Oct 25, 2018 at 10:32 AM Gus Heck <[hidden email]> wrote:
Or we could corral the naming of our tests into one pattern...

On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
Reply | Threaded
Open this post in threaded view
|

Re: Test Harness behaviour on a package run

Mark Miller-3
+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 <[hidden email]> wrote:
+1 to standardize test class naming!

On Thu, Oct 25, 2018 at 10:32 AM Gus Heck <[hidden email]> wrote:
Or we could corral the naming of our tests into one pattern...

On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
--
Reply | Threaded
Open this post in threaded view
|

Re: Test Harness behaviour on a package run

Christine Poerschke (BLOOMBERG/ LONDON)
In reply to this post by Varun Thacker-4
+1 to test class name standardisation.

https://issues.apache.org/jira/browse/SOLR-12939 just opened to make a minimal start on this, both the standardisation and incremental precommit enforcement.

Christine

From: [hidden email] At: 10/25/18 16:31:10
To: [hidden email]
Subject: Re: Test Harness behaviour on a package run
+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 <[hidden email]> wrote:
+1 to standardize test class naming!

On Thu, Oct 25, 2018 at 10:32 AM Gus Heck <[hidden email]> wrote:
Or we could corral the naming of our tests into one pattern...

On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
--