On 25 Nov 2013, at 10:19 am, Szczepan Faber <szczepan.fa...@gradleware.com> 
wrote:

> Thanks again for feedback. We'll consider it.
> 
> Regarding method separator - I'll discuss this with Adam.
> 
> >gradle test --include FooTest.bar --include FooTest.baz
> 
> I like --include. The reasons I ruled it out initially are:
> 
> 1. 'include' does not indicate that we're running 'only' this test.

In isolation it does. That's what test.include means.

> 2. It clashes with test.include which is going to stay and it works on a 
> different level. E.g. test.include / test.exclude is a way do declare where 
> the tests are and the input is based on ant file patterns (and will not 
> support methods).

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?).

All of that said, backwards compatibility may force our hand here. But, I still 
think we should try hard to avoid adding new concepts.

> 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.

> 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


Reply via email to