Thanks for the detailed information, I'll create a JIRA issue for improved integration testing.
As for the latter question, inside my TaskAction method I've simply been calling: dependsOn(project.tasks['dependency'],type:DependentTask) Will check to see if this approach does show the dep in 0.9-rc1 using --all. On Wed, Aug 4, 2010 at 4:22 PM, Adam Murdoch <[email protected]> wrote: > On 4/08/10 3:03 AM, Russ Rollins wrote: > > In testing my custom plugin and custom tasks, when the task is executed in > the test the dependency task is not executed, though the task dependencies > are well-defined on the plugin (and in the TaskAction itself). > > Should the dependency be automatically executed/or perhaps my test is wrong > ? > > class CustomTaskTwoSpec extends Specification{ > > def "task dependency satisfied, first executed before second"(){ > setup: > Project project = ProjectBuilder.builder().build() > project.plugins.apply(SimplePlugin) > CustomTaskSecond taskTwo = > project.tasks.getByName(CustomTaskSecond.TASK_NAME) > > when: > taskTwo.execute() > > > Task.execute() will only execute the task itself, not the task's > dependencies. > > There's no good way to execute a task and all its task dependencies from a > test at the moment. The only real option is to use the GradleLauncher API, > which is probably a bit coarse-grained, as it works at the same level as the > command-line. > > Here's the approach we take to testing in Gradle itself: > - A unit test for each custom task which covers the execution of the task > itself, without caring about dependencies. Tasks don't define their own > dependencies. > - A unit test for each plugin which covers the apply() method. It simply > makes assertions that the task dependencies have been defined. It doesn't > actually execute the tasks. > - An integration test which uses GradleLauncher API to drive the plugin > and/or tasks from a test build. > > We're certainly missing some testing support at the higher levels. Perhaps > something like: > - A fixture at the same level as GradleLauncher, for writing integration > tests at the command-line level. At this level, the test sets up a test > build on the file system, runs the build, and then makes some assertions > about what happened. > - Something between that and ProjectBuilder, where the test sets up the > model programmatically, runs a task (and implicitly its dependencies), and > then makes some assertions about what happened. > > Could you add a JIRA issue if you'd like something to be added to the > testing support? > > > > > then: > taskTwo.message == "is done" > project.tasks.getByName(CustomTaskFirst.TASK_NAME).executed //FAIL > } > } > > class SimplePlugin implements Plugin{ > > void apply(Object project) { > project.tasks.add(CustomTaskFirst.TASK_NAME,CustomTaskFirst) > CustomTaskSecond secondTask = > project.tasks.add(CustomTaskSecond.TASK_NAME, CustomTaskSecond) > secondTask.dependsOn(CustomTaskFirst) > } > > } > > > And, on a similar note, should the dependency be redundant in terms of > the task defining its own dependency and the plugin also defining it (I > noticed that if the plugin doesn't define the dep then when gradle -t is run > the dep isn't shown)? > > > If a task defines a dependency, it should show up in gradle -t, the same > way as if the plugin defines it (in 0.9-rc-1 you need to add --all to see > the dependencies). How does the task define the dependency? > > > > -- > Adam Murdoch > Gradle Developerhttp://www.gradle.org > CTO, Gradle Inc. - Gradle Training, Support, Consultinghttp://www.gradle.biz > >
