+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: [email protected] At: 10/25/18 16:31:10To: [email protected] 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 <[email protected]> wrote: +1 to standardize test class naming! On Thu, Oct 25, 2018 at 10:32 AM Gus Heck <[email protected]> wrote: Or we could corral the naming of our tests into one pattern... On Wed, Oct 24, 2018 at 5:08 PM Varun Thacker <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] -- 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
