Using gradle testKit to run various build permutations

I’ve not used testKit before, but it sounded like it might be ideal to perform a test I had done in ant where I would compile our project several times with a bunch of different properties set each time to make sure recent changes had not broken any permutations of building the project (mainly setting different compiler directives).
The project is an Adobe AIR mobile app (iOS and android), not java.
I can’t get the basic hello world examples to run:
$ groovy BuildLogicFunctionalTest.groovy
Nov 18, 2015 5:57:04 PM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
WARNING: Module [groovy-nio] - Unable to load extension class [org.codehaus.groovy.runtime.NioGroovyMethods]
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/Users/hudsonansley/Documents/speakaboos/speakaboosmobileapp/BuildLogicFunctionalTest.groovy: 1: unable to resolve class org.gradle.testkit.runner.GradleRunner
@ line 1, column 1.
import org.gradle.testkit.runner.GradleRunner
^
and so on for all the testkit imports.

I’m sure I’m missing something obvious, so I hope someone can help me get a little further along…

I’ve not used testKit before, but it sounded like it might be ideal to perform a test I had done in ant where I would compile our project several times with a bunch of different properties set each time to make sure recent changes had not broken any permutations of building the project (mainly setting different compiler directives).

Sounds like a valid use case you could test with TestKit.

/Users/hudsonansley/Documents/speakaboos/speakaboosmobileapp/BuildLogicFunctionalTest.groovy:
1: unable to resolve class org.gradle.testkit.runner.GradleRunner

You are likely missing the dependency on TestKit via gradleTestKit(). For more information see the user guide (see section “Usage”) or one of the example that ships with the Gradle distribution.

Thanks very much for your help. I agree, but I don’t understand how that works. I am not making a plugin. I put that in the build script, but it did not appear to make any difference (the groovy code fails before it loads the build.gradle)

I put that in the build script, but it did not appear to make any difference (the groovy code fails before it loads the build.gradle)

The TestKit classes are not added to buildscript’s classpath by default as it is the case with the rest of the Gradle API.

I am not making a plugin.

You will need to assign gradleTestKit() to a configuration that is used for the classpath assigned to a Test task. The test class you write will need to create a Gradle build script that is used for test execution. Within this build script you can use the TestKit API. You will need to have this setup independent of testing a plugin or just a plain build script. I’d recommend having a look at the sample project samples/testKit/testKitJunit.

Thanks again, and I hope I’m not trying your patience, but I have been looking at those examples, and I get the same errors, so I assume I don’t know how to run them or something.
From the directory with the build.gradle file, for example, I tried to run the groovy example with
groovy src/test/groovy/org/gradle/sample/BuildLogicFunctionalTest.groovy
and got the same “unable to resolve class org.gradle.testkit…” errors
Could you give me the command lines I should run for the sample files?

@Hudson_Ansley Please provide your build script so we can identify your issue. It’s very likely just a problem with how you assign the TestKit dependency.

ah, I see the issue now. I did not understand where to look for the test results. Thanks for your patients and sorry for the noise.

So I have this working nicely to check compilation with various compiler directive combinations, but the “test” task considers itself UP-TO-DATE when it runs successfully and the test code has not changed. Is it possible to add inputs to the test task so it checks if the projects source code has changed as part of the UP-TO-DATE check?

I worked around this issue by using

test.outputs.upToDateWhen { false }

since test is only run when something has changed in the source, this works well