Java Reference
In-Depth Information
Now if I run the same build task again, the integration test runs at the proper time:
prompt> gradle -m build
:compileJava SKIPPED
:processResources SKIPPED
:classes SKIPPED
:war SKIPPED
:assemble SKIPPED
:jettyRun SKIPPED
:compileTestJava SKIPPED
:processTestResources SKIPPED
:testClasses SKIPPED
:intTest SKIPPED
:test SKIPPED
:check SKIPPED
:build SKIPPED
BUILD SUCCESSFUL
Note that the jettyRun task is also triggered before the tests. Now everything works the
way I want.
From one perspective, this is quite a feat of engineering. The class structure in Gradle
makes it easy to define new tasks, I can make sure my task runs at the proper time, and I
can even embed the test as Groovy code right in my build file.
The problem, of course, is that I can embed the test as Groovy code right in my build file.
That works in this instance, but doing business logic (even testing) in a build file can't be
a good long-term solution. Test cases aren't part of a build; a build calls them. Inside the
build, they're hard to maintain and not easily reusable.
10.3.4. Using an integration-test source tree
A good way to separate the testing infrastructure from the actual tests is to create a special
source tree for it. That provides a convenient location for the tests, which will run automat-
ically at the proper point in the build.
Gradle projects have a sourceSets property, which can be used to map source director-
ies if they don't fit the default Maven pattern. An example of this was given in chapter 5 .
Search WWH ::




Custom Search