> > Why shouldn't it work the same way? I don't see the value in introducing > _another_ mechanism on top of includes/excludes other than simplifying the > implementation. Introducing an extra mechanism seems like extra complexity > for the user (i.e. what's the difference between test inclusion and test > selection?). >
Not sure. To me, it feels that there are 2 inputs: where are the tests (e.g. physical location) and what tests to execute (regexp on methods / classes, classes of type X, classes with certain annotations, some runtime conditions etc.). > All of that said, backwards compatibility may force our hand here. But, I > still think we should try hard to avoid adding new concepts. > Exactly right. > I'm not hardcoded on --only, just couldn't come up with anything better > under current circumstances. Perhaps my reasons are not strong enough we > can go ahead with --include? > > We can only use --include if it's just a way to add a test.include pattern > from the command line. If the semantics are different in any way we can't > use it. > Agreed. In this case, the semantics are different (we want to specify the method). > > It's undecided yet how to specify multiple only tests but we might allow > something like: > > > > gradle --only FooTest,BarTest,BazTest.xxx > > > > Cheers! > > > > > > On Sat, Nov 23, 2013 at 5:36 PM, kelemen <attila.keleme...@gmail.com> > wrote: > > I'm with Luke in this case regarding the separator character. Two of the > > benefits of '#': > > > > - Test method calls and test classes are easily distinguishable by > looking > > at them. > > - Using "." will leave the user wonder: "How does it know I'm referring > to a > > method?" which could be a source of misunderstanding. > > > > By the way, using "::" instead of "#" would be consistent with Java 8 > > notation (not that it is really that important). > > > > To me however, it is more important that I can start the test method from > > the command line and a clear (unambigous) syntax would be better here. I > > believe why it is mostly needed is to (re)test a single method when > > something is broken (and is assumed to be fixed) which is not a > predefined > > set of test methods. Although probably there are good cases for the > > predefined set of methods (to group quicker tests, etc.). > > > > > > > > -- > > View this message in context: > http://gradle.1045684.n5.nabble.com/supporting-the-execution-of-a-particular-test-method-tp5711996p5712039.html > > Sent from the gradle-dev mailing list archive at Nabble.com. > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > -- > > Szczepan Faber > > Principal engineer@gradle; Founder@mockito > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Szczepan Faber Principal engineer@gradle; Founder@mockito
