Hi,
Am Di, 22.02.2011, 02:38, schrieb Jason Porter:
> On Mon, Feb 21, 2011 at 16:55, Adam Murdoch <[email protected]> wrote:
>
>>
>> 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
>>
>>
>>
>
> Wasn't there a Hackergarten that created a rule to do this? Might need
> to be re-factored based on this though.
I think you're speaking about this
http://www.practicalgradle.org/blog/2011/01/convenient-test-execution-with-camel-case-support/
regards,
René
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
