The discussion of testing with Gradle takes two primary directions. The first is the simple testing of Java classes with existing test frameworks like JUnit and TestNG. The second is a full automation of the testing pipeline, including separating integration tests from unit test and the leveraging of more advanced testing frameworks like Spock and Geb.
The simplest JUnit example is almost
entirely supplied by the
plug-in. It adds the
test task to the
build graph and needs only the appropriate JUnit JAR to be added to the
classpath to fully activate test execution. This is demonstrated in
Example 5-1. Testing Java source with JUnit
The report from the execution of the JUnit tests is quite handsome compared to its non-Gradle counterparts, as you can see in Figure 5-1. It offers a summary of the tests that were executed, succeeded, and failed.
Figure 5-1. JUnit Test Report
When JUnit tests reach a certain level of proliferation within a
project, there is a motivation to run them in parallel to get the
results faster. However, there would be a great overhead to running
every unit test in its own JVM. Gradle provides an
intelligent compromise in that it offers a
maxParallelForks that governs the maximum simultaneous JVMs that are spawned. ...