Re: Test Harness behaviour on a package run
+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: dev@lucene.apache.org At: 10/25/18 16:31:10To: dev@lucene.apache.org 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 wrote: +1 to standardize test class naming! On Thu, Oct 25, 2018 at 10:32 AM Gus Heck wrote: Or we could corral the naming of our tests into one pattern... On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker 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 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 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 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 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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@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
+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 wrote: > +1 to standardize test class naming! > > On Thu, Oct 25, 2018 at 10:32 AM Gus Heck wrote: > >> Or we could corral the naming of our tests into one pattern... >> >> On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker 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 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 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 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 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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@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
+1 to standardize test class naming! On Thu, Oct 25, 2018 at 10:32 AM Gus Heck wrote: > Or we could corral the naming of our tests into one pattern... > > On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker 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 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 >>> 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 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 >>> 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-unsubscr...@lucene.apache.org >>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>> > >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@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
Or we could corral the naming of our tests into one pattern... On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker 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 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 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 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 >> 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-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> -- http://www.the111shift.com
Re: Test Harness behaviour on a package run
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 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 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 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 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-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Test Harness behaviour on a package run
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 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 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 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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Test Harness behaviour on a package run
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 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 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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?
