7.5. Running Spock tests as part of a build process

So far, I’ve silently assumed that whenever I show you a Spock test, you run it manually and visually check the results in the IDE or the command-line shell. Although this is true for your day-to-day development schedule, a well-designed enterprise application employs a build server that automatically checks out code at various time intervals, compiles it, runs unit tests, and creates reports in a completely automated manner.

If you’re not familiar with build servers, explaining them is outside of the scope of this book. As a suggestion, start by downloading Jenkins (https://jenkins-ci.org/) and then read both the theory^[24] and practice^[25] behind a sound build process.

²⁴

See “Continuous Delivery” by Jez Humble and David Farley on the Martin Fowler website (http://martinfowler.com/books/continuousDelivery.html).

²⁵

See Jenkins: The Definitive Guide by John Ferguson Smart (O’Reilly, 2011), www.wakaleo.com/books/jenkins-the-definitive-guide.

For the rest of the chapter, I assume that you already have a build server in place for running JUnit tests and mention only what you need to do for Spock (spoiler: almost nothing, as Spock is JUnit-compatible).

7.5.1. Splitting unit, integration, and functional tests

If you look back at table 7.1, which lists the characteristics of unit, integration, and functional tests, it should be clear that they have different requirements.

For starters, functional (and sometimes integration) tests require a running replica of the system that’s tested. Therefore, you know that functional tests must be treated differently than the rest of the tests.

Another big difference is the speed of tests. Unit tests (which depend only on Java code) are fast and give quick feedback. Integration and functional tests are much slower (especially when external systems and real databases are involved).

The speed of unit tests means that they can be executed automatically after every developer commit for quick feedback. Functional tests, on the other hand, may run less frequently (for example, once a day) and also require the setup of a test environment exclusive to them (which typically replicates the production environment).

These best practices aren’t specific to Spock. They also apply to JUnit or TestNG. I mention them here so that before complaining that “Geb tests are really slow,” you should understand that Geb tests must run in a different manner than simpler Spock tests.

In the sample code of the book, I use Maven and have chosen to launch the Tomcat application server before the functional tests run. Figure 7.14 shows the Maven life-cycle^[26] for the examples of this chapter.

²⁶

You can learn more about the Maven lifecycle at the Apache Maven Project website (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html).

Figure 7.14. Tomcat is launched before functional tests and shuts down afterward.

With this approach, you have a split between slow and fast tests. Running mvn test runs only the fast unit tests, and running mvn verify also runs the slow functional tests (after launching a Tomcat instance). This lifecycle is accomplished by using the Maven Failsafe plugin (https://maven.apache.org/surefire/maven-failsafe-plugin/) and the Tomcat plugin (http://tomcat.apache.org/maven-plugin.html), as shown in the following listing.

Listing 7.13. Running Spock functional tests on a Tomcat instance

This technique works for small- to medium-size applications. For large-scale enterprise applications that need specialized test environments, you need to adapt your build system according to your business requirements in cooperation with the team responsible for provisioning.^[27]

²⁷

I hear they’re called “devops” these days.

7.5.2. Getting code coverage from Spock tests

For some strange reason, when I introduce Spock to Java developers, even after I explain that it uses the JUnit runner, the first question they ask is how to obtain code coverage statistics with Spock.

The answer to this question is, “In the same way that you get coverage reports^[28] for JUnit.” There’s nothing special about it. Figure 7.15 shows a sample JaCoCo report (www.eclemma.org/jacoco/) that was generated by Spock tests.

²⁸

Common coverage tools are Cobertura (http://cobertura.github.io/cobertura/) and Clover (www.atlassian.com/software/clover/).

Figure 7.15. Code coverage by Spock tests

There’s nothing Spock-specific about this report. I obtained it by adding JaCoCo in my pom.xml file and executing the jacoco:report goal with Maven as I would for JUnit, as shown in the following listing.

Listing 7.14. Using JaCoCo with Spock

[...rest of build plugins here...]
<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.7.4.201502262128</version>
    <executions>
    <execution>
            <id>prepare-agent</id>
            <goals>
            <goal>prepare-agent</goal>
            </goals>
    </execution>
    </executions>
</plugin>
[...rest of pom.xml here...]

The same principle applies to any other tools that you have around JUnit. If they work fine with JUnit, they’ll probably work with Spock as well. For a full-blown, code-quality reporting tool, you should also look at SonarQube (www.sonarqube.org) if you aren’t already using it.

Figure 7.16. Code coverage from SonarQube after Spock tests run

Using Spock with SonarQube requires exactly zero extra configuration (apart from the standard instructions^[29]). An example of SonarQube results from a Spock test is shown in listing 7.16.

²⁹

An excellent resource is SonarQube in Action by G. Ann Campbell and Patroklos P. Papapetrou (Manning, 2013), www.manning.com/papapetrou/.

I hope that the level of compatibility between JUnit-enabled tools and Spock tests is clear to you now.