On 27/08/2011, at 7:11 PM, Luke Daley wrote:
>
> 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
The difference here is in scope. All of our plugins have a unit test similar to
your example, where the plugin is applied, and we check how the domain objects
end up configured and what happens when you tweak that configuration.
My example above is not a unit test. The test (intentionally) does some work,
rather than just configuring some domain objects. It exercises a heap of code
in core, coreImpl, wharf and ivy. It also uses a real http repository, and a
user home directory that is being used concurrently by other test processes. It
must also run in as close approximation to a real build script - which mean
running against the real distribution, in a separate process, with the real
classloader set up, as if a human had run 'gradle mytesttask'.
But, we also want the test to scale down in accuracy at dev time, so that it's
faster and I can run and debug it in the IDE without having to run any build
tasks.
Plus, we want the test to be reusable, so that the same test can be used to
verify behaviour for any of the the ways that Gradle can be invoked: from the
command-line, from the command-line with the daemon, through the tooling API,
through the Gradle GUI, via the wrapper, and later, remotely.
Ideally, we also want to reuse some of these tests as smoke tests for our
release process, where we do things such as simulate the user updating their
wrapper properties to point to the new distribution and run these tests.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
