1.7. Comparing Spock and JUnit

Comparing JUnit and Spock in a single section is difficult because both tools have a different philosophy when it comes to testing. JUnit is a Spartan library that provides the absolutely necessary thing you need to test and leaves additional functionality (such as mocking and stubbing) to external libraries.

Spock takes a holistic approach, providing a superset of the capabilities of JUnit, while at the same time reusing its mature integration with tools and development environments. Spock can do everything that JUnit does and more, keeping backward compatibility as far as test runners are concerned.

What follows is a brief tour of some Spock highlights. Chapter 3 compares similar functionality between Spock and JUnit. If you’re not familiar with JUnit, feel free to skip the comparisons and follow the Spock examples.

1.7.1. Writing concise code with Groovy syntax

Spock is written in Groovy, which is less verbose than Java. Spock tests are more concise than the respective JUnit tests. This advantage isn’t specific to Spock itself. Any other Groovy testing framework would probably share this trait. But at the moment, only Spock exists in the Groovy world. Figure 1.15 shows this advantage in a visual way.

Figure 1.15. Amount of code in an application with JUnit and Spock tests

Less code is easier to read, easier to debug, and easier to maintain in the long run. Chapter 3 goes into more detail about how Groovy supports less-verbose code than Java.

1.7.2. Mocking and stubbing with no external library

JUnit doesn’t support mocking and stubbing on its own. Several Java frameworks fill this position. The main reason that I became interested in Spock in the first place is that it comes “batteries included,” with mocking and stubbing supported out of the box. As figure 1.16 shows, it does even more than that.

Figure 1.16. Spock is a superset of JUnit.

I’ll let this example explain:

David goes into a software company and starts working on an existing Java code base. He’s already familiar with JUnit (the de facto testing framework for Java). While working on the project, he needs to write some unit tests that need to run in a specific order. JUnit doesn’t support this, so David also includes TestNG in the project.

Later he realizes that he needs to use mocking for some special features of the software (for example, the credit card billing module), so he spends time researching all the available Java libraries (there are many). He chooses Mockito and integrates it into the code base.

Months pass, and David learns all about behavior-driven development in his local dev meeting. He gets excited! Again he researches the tools and selects JBehave for his project in order to accomplish BDD.

Meanwhile, Jane is a junior developer who knows only vanilla Java. She joins the same company and gets overwhelmed the first day because she has to learn three or four separate tools just to understand all the testing code.

In an alternate universe, David starts working with Spock as soon as he joins the company. Spock has everything he needs for all testing aspects of the application. He never needs to add another library or spend time researching stuff as the project grows.

Jane joins the same company in this alternate universe. She asks David for hints on the testing code, and he replies, “Learn Spock and you’ll understand all testing code.” Jane is happy because she can focus on a single library instead of three.

You’ll learn more about stubbing/mocking/spying in chapter 6. The semantics of Spock syntax are covered in chapter 4.

1.7.3. Using English sentences in Spock tests and reports

The next listing presents a questionable JUnit test (I see these all the time). It contains cryptic method names that don’t describe what’s being tested.

Listing 1.7. A JUnit test with method names unrelated to business value

Only programmers can understand this code. Also, if the second test breaks, a project manager (PM) will see the report and know that “scenario2” is broken. This report has no value for the PM, because he doesn’t know what scenario2 does without looking at the code.

Spock supports an English-like flow. The next listing presents the same example in Spock.

Listing 1.8. A Spock test with methods that explain the business requirements

Even if you’re not a programmer, you can read the English text in the code (the sentences inside quotation marks) and understand the following:

• The client should get a bonus if he spends more than 100 dollars.
• When a client buys something with a value of at least 100, then the client should have the bonus option active.
• The client loses the bonus if he doesn’t accept the transaction.
• When a client buys something and later changes his mind, then the client should have the bonus option inactive.

This is readable. A business analyst could read the test and ask questions about other cases. (What happens if the client spends $99.99? What happens if he changes his mind the next day rather than immediately?)

If the second test breaks, the PM will see in the report a red bar with the title “Client loses bonus if he doesn’t accept the transaction.” He instantly knows the severity of the problem (perhaps he decides to ship this version if he considers it noncritical).

For more information on Spock reporting and how Spock can be used as part of an enterprise delivery process, see chapter 7.