On 10/02/10 2:36 AM, Peter Ledbrook wrote:
Not really. But they could be, with some tidy-up.
For Gradle, we have 2 types of tests for plugins:
1. The test uses a fixture to create a Project instance, which the test
drives programmatically eg
@Test pluginDoesSomeStuff() {
Project project = createRootProject()
project.apply type: MyCustomPlugin
// Make some assertions about what the plugin has done to the project
}
2. The test uses a fixture to execute a Gradle build. There are 2
implementations: one uses the GradleLauncher API to run the build in
process, and one forks the gradle command to run the build in a child
process. E.g:
@Test pluginDoesSomeStuff() {
File buildFile = ...
buildFile<< '''
apply type: MyCustomPlugin
// maybe some other stuff
'''
executer.usingBuildFile(buildFile).withTasks('someTask').run()
// make some assertions about what the build has done
}
Is this the sort of thing you had in mind?
Yes. I think a combination of both would probably be ideal.
Could you add a JIRA issue for this?
In the meantime, you could use GradleLauncher. For example, to get a
project instance you could pass it an empty build file, and use the
result from GradleLauncher.getBuildAnalysis()
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
