On 27/08/2011, at 5:53 AM, Adam Murdoch wrote:
> We have some int tests that drive the dsl, then make some assertions about
> the model. For example, our dependency management int tests are structured
> this way. Imagine something like this:
>
> class DependencyManagementIntegrationTest extends BuildSpecification {
> def "can do some stuff"() {
> when:
> apply plugin: 'java'
> repositories { mavenCentral() }
> dependencies { compile 'junit:junit:4.8.2' }
>
> then:
> configurations.compile.files.collect { it.name } ==
> ['junit-4.8.2.jar']
> }
> }
>
> where the whole test method is run effectively as a build script against the
> DSL.
Would you need an integration test for this?
I did something similar for the signing plugin using ProjectHelper:
https://github.com/gradle/gradle/blob/master/subprojects/signing/src/test/groovy/org/gradle/plugins/signing/SigningConfigurationsSpec.groovy
> We also have a heap of integration tests that need to run given a certain
> build script. So, it might be nice to have something like:
>
> class JavaPluginIntegrationTest extends GradleSpecification {
> def "can do some stuff"() {
> given:
> buildScript {
> apply plugin: 'java'
> }
>
> when:
> run 'build'
>
> then:
> taskExecuted ':compile'
> }
> }
>
> where you can embed build scripts in the test as code, rather than as strings.
I can see how this would work using my groovy-remote project:
http://groovy.codehaus.org/modules/remote/
It would allow you to pass the closure given to build script across a class
loader or even JVM boundary.
This might be a good option to have, if for nothing else than the better
developer experience using real code as opposed to strings.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
