1.6. Spock’s position in the Java ecosystem

The de facto testing framework in a Java project is JUnit, but TestNG is another testing framework for Java that’s similar. At one point, TestNG had several extra features that JUnit lacks, resulting in a lot of developers switching over to TestNG (especially for big enterprise projects). But JUnit quickly closed the gap, and TestNG failed to gain a majority in the mindset of Java developers. The throne of JUnit is still undisputed. I’ve seen junior Java developers who think that JUnit and unit testing are the exact same thing. In reality, JUnit is one of the many ways that unit tests can be implemented.

Unit tests in both JUnit and TestNG are written in Java as well. Traditionally, this has been seen as an advantage by Java developers because they use the same programming language in both production code and testing code. Java is a verbose language (at least by today’s standards) with a lot of boilerplate code, several constraints (for example, all code must be part of a class, even static methods), and a heavy syntax requiring everything to be explicitly defined. Newer editions of Java (after version 7) attempt to rectify this issue with mixed success, never reaching the newer “convention-over-configuration” paradigm of other programming languages.

It doesn’t have to be this way, though. There’s no technical reason to constrain unit tests so that they’re in the same programming language as the development code. In fact, production and testing code have completely different requirements. The biggest difference is that testing code runs by definition before the application is deployed in production. A good engineer uses the best tool for the job. You can think of Spock as a special domain language created exclusively for testing purposes.

Compilation and running of unit tests is a common task for the developer or the build server inside a software company. Runtime and compile-time errors in unit tests are detected at the same time. Java goes to great lengths to detect several errors during compile time instead of runtime. This effort is wasted in unit tests because these two phases usually run one after the other during the software development lifecycle. The developer still pays the price for the verbosity of Java, even for unit tests. There must be a better way.

Groovy comes to the rescue!

1.6.1. Making Spock Groovy

Groovy is a dynamic programming language (similar to Python or Ruby), which means it gives the programmer power to defer several checks until runtime. This might seem like a disadvantage, but this feature is exactly what unit tests should exploit. Groovy also has a much nicer syntax than Java because several programming aspects have carefully selected defaults if you don’t explicitly define them (convention over configuration).

As an example, if you omit the visibility modifier of a class in Java, the class is automatically package private, which ironically is the least used modifier in Java code. Groovy does the logical thing: if you omit the visibility modifier of a class, the class is assumed to be public, which is what you want most times.

The times that I’ve had to create JUnit tests with package private visibility in my programming career: zero! For all these years, I’ve “paid” the price of declaring all my unit tests (and I guess you have, as well) as public, without ever thinking, “There must be a better way!” Groovy has embraced the convention-over-configuration concept, and this paradigm is evident in Spock code as well.

With Spock, you can gain the best of both worlds. You can keep the tried-and-true Java code in your core modules, and at the same time, you gain the developer productivity of Groovy in the testing code without sacrificing anything in return. Production code is written with verbose and fail-safe Java code, whereas unit tests are written in the friendlier and lighter Groovy syntax that cuts down on unneeded modifiers and provides a much more compact code footprint. And the best part is that you keep your existing JUnit tests!

1.6.2. Adding Spock tests to existing projects that have JUnit tests

Every new technology faces a big obstacle in its path to adoption: resistance to change. Tradition, inertia, and the projected cost of switching to another technology instead of the mature existing solution are always major factors that affect any proposal for improvement when a better solution comes along.

As an example, Gradle is a build system, also written in Groovy, which is in many ways more flexible than the de facto build system of Java (Maven). Using two build systems in a big enterprise project is unrealistic. Gradle has to face the entrenched Maven supporters and convince them that the switch offers compelling advantages.

Spock doesn’t suffer from this problem. You can integrate Spock today in your Java project without rewriting or removing a single line of code or configuration. This is a huge win for Spock because it allows a gradual adoption; both old JUnit tests and newer Spock tests can coexist peacefully. It’s perfectly possible to implement a gradual Spock adoption strategy in your organization by implementing new tests in Spock during a trial period without losing anything if you decide to keep implementing JUnit tests as well.

The standard Maven directory structure is flexible in accommodating multiple programming languages. Groovy source code is usually placed in the src/test/groovy folder so that the Groovy compiler plugin can find it. All your Spock tests can go into this directory without affecting your existing JUnit tests located in src/test/java (or other directories), as shown in figure 1.13.

Figure 1.13. Spock tests in a Maven project with existing JUnit tests

For more details on how to set up your IDE for Spock testing, see appendix A.

With the Spock tests in place, the next question you might have is how to run them. You’ll be happy to know that Spock comes with a test runner called Sputnik (from Spock and JUnit) that runs on top of the existing JUnit runner, thus keeping full backward compatibility.

You can run any Spock test as you run any JUnit test:

• From your development environment
• From the command line
• From Maven/Gradle or any other build system that supports JUnit tests
• From an automated script or build server environment (as explained in chapter 7)

1.6.3. Spock adoption path in a Java project

Because Spock is compatible with JUnit runners, it can be introduced gradually in an existing Java code base. Assuming you start with a 100% Java project, as shown at the top left of figure 1.14, Spock can run alongside JUnit tests in the same code base.

Figure 1.14. Gradual invasion of Spock tests in an existing Java project with JUnit tests

It’s possible to rewrite all tests in Spock if that’s what you want. Spock can work as a superset of JUnit, as you’ll see in chapter 3. That situation is shown in the third scenario, depicted at the far right of figure 1.14.

For this book, I assume that you have no prior experience with Groovy. Chapter 2 is fully devoted to Groovy features, and I’ll also be careful to explain which new syntax is a feature of Spock and which is a feature of Groovy.