1.5. A first look at Spock in action

The following examples should whet your appetite, so don’t stress over the strange syntax or any unknown keywords. I cover Spock syntax throughout the rest of the book.

1.5.1. A simple test with JUnit

When introducing a new library/language/framework, everybody expects a “hello world” example. This section shows what Spock looks like in a minimal, but fully functional example.

The following listing presents the Java class you’ll test. For comparison, a possible JUnit test is first shown, as JUnit is the de facto testing framework for Java, still undisputed after more than a decade.

Listing 1.2. Java class under test and JUnit test

You introduce two test methods, one that tests the core functionality of your Adder class, and one that tests the order of arguments in your add method.

Running this JUnit test in the Eclipse development environment (right-click the .java file and choose Run As > JUnit Test from the menu) gives the results shown in figure 1.9.

Figure 1.9. Running a JUnit test in Eclipse

1.5.2. A simple test with Spock

The next listing shows the same test in Groovy/Spock. Again, this test examines the correctness of the Java class Adder that creates the sum of two numbers.

Listing 1.3. Spock test for the Adder Java class

If you’ve never seen Groovy code before, this Spock segment may seem strange. The code has mixed lines of things you know (for example, the first line with the extends keyword) and things completely alien to you (for example, the def keyword). Details on Groovy syntax are explained in chapter 2.

On the other hand, if you’re already familiar with BDD, you’ll already grasp the when/then pattern of feature testing.

The upcoming chapters explain Spock syntax in detail. For example, the def keyword (which stands for define) is how you declare things in Groovy without explicitly specifying their type (which is a strict requirement in Java). The Spock blocks (when:, then:, and:) are covered in chapter 4.

How do you run this test? You run it in the same way as a JUnit test! Again, right-click the Groovy class and choose Run As > JUnit Test from the pop-up menu. The result in Eclipse is shown in figure 1.10.

Figure 1.10. Running a Spock test in Eclipse

Other than the most descriptive method names, there’s little difference between the JUnit and Spock results in this trivial example. Although I use Eclipse here, Spock tests can run on all environments/tools that already support JUnit tests (for example, IntelliJ IDEA).

Takeaways from these code examples

Here’s what you need to take away from this code sample:

• The almost English-like flow of the code. You can easily see what’s being tested, even if you’re a business analyst or don’t know Groovy.
• The lack of any assert statements. Spock has a declarative syntax, which explains what you consider correct behavior.
• The fact that Spock tests can be run like JUnit tests.

Let’s move on to one of the killer features of Spock (handling failed tests).

1.5.3. Inspecting failed tests with Spock

One of the big highlights of Spock code is the lack of assert statements compared to JUnit. In the previous section, you saw what happens when all tests pass and the happy green bar is shown in Eclipse. But how does Spock cope with test failures?

To demonstrate its advantages over JUnit, you’ll add another (trivial) Java class that you want to test:

public class Multiplier {
     public int multiply(int a, int b)
     {
            return a * b;
     }
}

For this class, you’ll also write the respective JUnit test, as shown in the following listing. But as an additional twist (for demonstration purposes), you want to test this class not only by itself, but also in relation to the Adder class shown in the previous section.

Listing 1.4. A JUnit test for two Java classes

Running this unit test results in a green bar because both tests pass. Now for the equivalent Spock test, shown in the next listing.

Listing 1.5. Spock test for two Java classes

Again, running this test will pass with flying colors. You might start to believe that we gain nothing from using Spock instead of JUnit. But wait!

Let’s introduce an artificial bug in your code to see how JUnit and Spock deal with failure. To mimic a real-world bug, you’ll introduce it in the Multiplier class, but only for a special case (see the following listing).

Listing 1.6. Introducing an artificial bug in the Java class under test

Now run the JUnit test and see what happens (figure 1.11).

Figure 1.11. Failure of JUnit test in Eclipse

You have a test failure. But do you notice anything strange here? Because the bug you introduced is subtle, JUnit says this to you:

• Addition by itself works fine.
• Multiplication by itself works fine.
• When both of them run together, we have problem.

But where is the problem? Is the bug on the addition code or the multiplication? We can’t say just by looking at the test result (OK, OK, the math might give you a hint in this trivial example).

You need to insert a debugger in the unit test to find out what happened. This is an extra step that takes a lot of time because re-creating the same context environment can be a lengthy process.

Spock knows all the details when a test fails

Spock comes to the rescue! If you run the same bug against Spock, you get the message shown in figure 1.12.

Figure 1.12. Failure of a Spock test in Eclipse

Spock comes with a super-charged error message that not only says you have a failure, but also calculates intermediate results!

As you can see, it’s clear from the test that the addition works correctly (2 + 3 is indeed 5) and that the bug is in the multiplication code (4 × 5 doesn’t equal 25).

Armed with this knowledge, you can go directly to the Multiplier code and find the bug. This is one of the killer features of Spock, and may be enough to entice you to rewrite all your JUnit tests in Spock. But a complete rewrite isn’t necessary, as both Spock and JUnit tests can coexist in the same code base, which you’ll explore next.