On 22/02/2011, at 3:53 AM, Peter Niederwieser wrote: > > As I've learned today, the correct way to run a single test class is > "-D<testTaskName>.single=FooTest". (Before I had thought that it's always > "-Dtest.single=FooTest".) How about using a fixed system property instead? > This would make the feature easier to use. > > One potential downside of using a fixed system property is that it would > make it more difficult to fail the build if the naming pattern doesn't match > anything (we would have to consider all test tasks to make this decision). > But since this feature is mostly used interactively, I don't even consider > it essential (though probably desirable) to fail the build. > > Since -Dtest.single is really about running a subset of tests, I also wonder > if we could come up with a better name (e.g. -Dtest.include). But this is a > minor complaint. > > Thoughts?
Using system properties just does't seem like the way to go. They're too imprecise, in that they apply globally, and opaque, in that there's no good way to discover what system properties are available for me to use. Instead, I think a command-line option might be better: gradle test --include SomePattern and gradle core:test --include SomePattern plugins:test --include SomeOtherPattern Or, more generally: gradle <task-independent-options> [<task> <task-specific-options>]... We would drive these using meta-data on the Test task type, so provide a general purpose way to tweak the model from the command-line. We already use this approach for 'gradle tasks --all', so it's just a matter of handling more types of properties (the implementation only handles boolean properties at the moment). Given that this is driven from the model, we can also provide the same options to tweak the configuration via the GUI/IDE, and can offer some way to discover the options using, say, 'gradle help <task>'. -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
