On 26 Nov 2013, at 12:19 am, Philip Crotwell <crotw...@seis.sc.edu> wrote:
> > > > On Sat, Nov 23, 2013 at 11:36 AM, 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.). > > Hi > > I also think the retest of a failure is the most likely use case. It would be > really nice if gradle could print the command line that execs just the single > failed test as part of the test report for that test to allow easy > "cut-paste-retest". > > As long as it is easy, the syntax probably doesn't matter, but I don't see > the benefit of an easily distinguishable method vs class syntax to the user. > If I say "gradle, please run test A.B.C" and C happens to be a method, what > is the advantage of gradle responding "I'm sorry Dave, I can't do that"? > Seems to me that if it is easy to figure out what the user wants to do, > gradle should just do it. +1 -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
