On 22 Nov 2013, at 9:43 am, Szczepan Faber <szczepan.fa...@gradleware.com> 
wrote:

> Thanks for feedback guys.
> 
> Using '#' makes the implementation much easier, because it's very clear where 
> the class qualified name ends and when the method name starts. Still, the 
> current plan is to use '.' because Adam & me prefer it. As far as command 
> line is concerned I'll make the implementation dead simple (for starters), 
> e.g. assume that if the last word is lowercase it's a method. For special 
> cases, one can always declare the method in the build script via dsl.

I think this (not using a different delimiter) is a bad idea. This kind of 
implicitness produces awkward corner cases and makes things more complex.

A good example of this is the ambiguity around class literals in Groovy. 

> 
> Currently, in Gradle master here's how you can declare specific method via 
> dsl:
> 
> test {
>   selection {
>     includeMethod 'someMethod'
>   }
> }
> 
> The dsl is not finalized but I needed to start with something (and spark 
> discussion and review). The command line would be probably something like:
> 
> gradle test --only FooTest.bar

Why use a different strategy than the sum of includes and excludes like we 
already do? It's more flexible than “only”.

E.g. this makes no sense:

gradle test --only FooTest.bar --only FooTest.baz

While this does:

gradle test --include FooTest.bar --include FooTest.baz

Even if we don't want to support more than one param on the CLI right now, I 
don't think we should shut that door with the naming.

> 
> Cheers!
> 
> 
> On Thu, Nov 21, 2013 at 10:14 PM, radimk <ra...@kubacki.cz> wrote:
> Hi,
> 
> I think '#' is OK. Special chars can be escaped. People are used to this
> char in JUnit runner and when writing Javadoc links. There was also mention
> of supporting both patterns: class name with '.' as delimiter and resource
> path with slashes where '$' can occur (I know it would be unusual to have
> static inner class as test). And this is another special char. Last but not
> least the fuzziness when deciding if there is a method name or not is good
> idea IMO.
> 
> -Radim
> 
> 
> 
> --
> View this message in context: 
> http://gradle.1045684.n5.nabble.com/supporting-the-execution-of-a-particular-test-method-tp5711996p5712034.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