On Tue, Oct 15, 2013 at 4:11 AM, Dawid Weiss <dawid.we...@cs.put.poznan.pl> wrote: >> Is this (the "globbing") really an important feature? Is it somehow >> necessary in the implementation for other reasons? > > There are a few reasons for that: > > - without globbing you'd have to provide a fully qualified class name > (and test name);
Hmm, you couldn't just enter the unqualified class name, and then it'd match any package containing that class name? LIke "**/TestFooBar" patternset pattern I think? > - Lucene doesn't use it but if we did have one test-covers-all type of > execution then you could run all of a given module's tests by giving > its package prefix, Hmm ok. > - remember that the test case "names" are not necessarily the method > name -- when repeat annotation (or sysprop) is used each test method > expands into multiple tests (the name then includes the seed and > repetition number if that's not enough to distinguish individual test > cases). These things stem from JUnit limitations. And globbing is a > simple way to run all test cases expanded from a single method. Hmm, so globs are a convenient way to work around a JUnit limitation? > I personally do use globbing to restrict to a package (when I wish to > test a single module), so it's not a dead feature :) Fair enough :) I feel you are putting the cart before the horse here, i.e. you are "implementation blind": you justify the current behavior (saying BUILD SUCCESSFUL when no test actually ran) because of the current implementation, i.e. "it's the glob pattern that matched nothing, and that's not an error in general". Whereas what I see is a nasty trap, when the user makes a typo (e.g. javac Foo*.java fails when there is no match), when an assumption is hit, etc. But at this point I think we simply disagree ... >> Another (third) trap I've hit is trying to run a single method, but >> accidentally running two because the first method is a prefix of the >> second one ... when this happens, I go and rename the methods so there >> is no prefix anymore. > > This is because in Lucene's ANT code there are backcompat settings > that expand testcase/testmethod into any substring match. If you used > tests.method and tests.class you could specify these accurately. Oh, I hadn't realized/remembered -Dtestmethod=XXX previously did substring (did you mean prefix?) expansion too! I also did not remember -Dtests.method=XXX was different.... I believe you've explained this many times already ;) I'll [hopefully remember to] use -Dtests.method from now on! Mike McCandless http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
