1.1. What is Spock?
This book is about Spock, a comprehensive testing framework for Java (and Groovy) code that can help you automate the boring, repetitive, and manual process of testing a software application. Spock is comprehensive because it’s a union of existing Java testing libraries, as shown in figure 1.1.
Figure 1.1. Spock among existing Java testing tools
As the figure shows, Spock is a superset of the de facto testing framework for Java: JUnit (http://junit.org/). Spock also comes with built-in capabilities for features that normally require additional libraries. At its core, Spock is a testing framework capable of handling the full lifecycle of a software application.
Spock was initially created in 2008 by Peter Niederwieser, a software engineer with Gradleware.[1] Inspired by existing test tools such as jMock (www.jmock.org) and RSpec (http://rspec.info/), Spock is used by several libraries within the open-source community, including Apache Tapestry (https://github.com/apache/tapestry-5) and MongoDB (https://github.com/mongodb/mongo-java-driver), and by several commercial companies (for instance, Netflix). A second Spock committer is Luke Daley (also with Gradleware), creator of the popular Geb functional testing framework (www.gebish.org) demonstrated in chapter 7. Spock, a new entry in the test framework arena, challenges the undisputed king—JUnit—armed with a bunch of fresh ideas against the legacy techniques of the past. Spock tests are written in Groovy, but they can test either Groovy or Java code.
The same company behind Gradle, a build system in Groovy (a replacement for Maven).
1.1.1. Mocking and stubbing
The most basic unit tests (called logic tests by some) are those that focus on the logic of a single Java class. To test a single class in a controlled environment and isolate it from the other classes it depends on (collaborators), Spock comes with built-in support for “faking” external object communication. This capability, known as mocking and stubbing, isn’t inside vanilla JUnit; you need external libraries—for example, Mockito (https://github.com/mockito/mockito) or jMock (http://www.jmock.org/)—to achieve this isolation of a Java class.
1.1.2. Behavior-driven development
Spock also embraces the paradigm of behavior-driven development (BDD), a development process that attempts to unify implementation, testing, and business people inside a software organization, by introducing a central way of documenting requirements and validating software functionality against those requirements, in a clear and repeatable manner. Spock combines these facets into a single convenient package offering a holistic approach to software testing.
1.1.3. Spock’s design features
Spock has the following characteristics.
Enterprise-ready
Spock can be easily integrated with the popular build systems, Maven (https://maven.apache.org/) and Gradle (https://gradle.org/). Spock runs as part of a build process and produces reports of automated test runs. Spock can be used to test back-end code, web pages, HTTP services, and more.
Comprehensive
Spock is a one-stop shop when it comes to testing. It has built-in capabilities for mocking and stubbing (creating fake objects), allowing you to decide on the breadth of the testing context. Spock can test a single class, a code module, or a whole application context with ease. You can perform end-to-end testing with Spock (covered in chapter 7) or isolate one class/method for your testing needs without any external libraries (described in chapter 6).
Familiar/compatible
Spock runs on top of the JUnit runner, which already enjoys mature support among tools and development environments. You run your Spock tests in the same way as your JUnit tests. You can even mix the two in the same project and get reports on test failures or code coverage in a similar way to JUnit. Run your tests in parallel or in a serial way; Spock doesn’t care because it’s fully compatible with existing JUnit tools.
Inspired
Spock is relatively new and doesn’t carry any legacy burden. It’s designed from scratch but at the same time it takes the best features of existing testing libraries (and tries to avoid their disadvantages). For example, Spock embraces the given-when-then structure of JBehave (http://jbehave.org/) but also discards the cumbersome record/replay code of older mocking frameworks.
1.1.4. Spock’s coding features
Spock’s coding features are as follows.
Concise
Spock uses the Groovy syntax, which is already concise and mixes its simplified syntax on top. No more tests that hide the substance with boilerplate code!
Readable
Spock follows a close-to-English flow of statements that can be readable even by nontechnical people (for example, business analysts). Collaboration among analysis, development, and testing people can be greatly simplified with Spock tests. If you always wanted to name your test methods by using full English sentences, now you can!
Meticulous
When things go wrong, Spock gives as much detail as possible on the inner workings of the code at the time of failure. In some cases, this is more than enough for a developer to understand the problem without resorting to the time-consuming debugging process.
Extensible
Spock allows you to write your own extensions to cater to your specific needs. Several of its “core” features are extensions (or started as extensions).
Listing 1.1 provides a sample test in Spock that illustrates several of these key coding features. The example shows a billing system that emails invoices to customers only if they have provided an email address.
You can find almost all code listings of this book at https://github.com/kkapelon/java-testing-with-spock. For brevity, the book sometimes points you to the source code (especially for long Java listings). I use the Eclipse integrated development environment (IDE) in my day-to-day work, as shown in the screenshots throughout the book. You can find specific instructions for installing Spock and using it via Maven, Gradle, Eclipse, and IntelliJ in appendix A.
Don’t be alarmed by unknown keywords at this point. Even if you know absolutely no Groovy at all, you should be able to understand the scenario in question by the presence of full English sentences. The following chapters explain all details of the syntax. All of chapter 2 is devoted to Groovy and how it differs from Java.
Listing 1.1. Sample Spock test
As you can see, the Spock test has a clear given-when-then flow denoted with labels (the BDD style of tests), and each label comes fully documented with an English sentence. Apart from the def keyword and the * symbol in the last two statements, almost all code is Java-like. Note that the spock.lang.Specification class is runnable by JUnit, meaning that this class can act as a JUnit test as far as build tools are concerned. Upcoming chapters cover these and several other features of Spock.
Testing is a highly controversial subject among software developers, and often the discussion focuses on testing tools and the number of tests that are needed in an application. Heated discussions always arise on what needs to be tested in a large application and whether tests help with deadlines. Some developers (hopefully, a minority) even think that all tests are a waste of time, or that their code doesn’t need unit tests. If you think that testing is hard, or you believe that you don’t have enough time to write tests, this book will show you that Spock uses a concise and self-documenting syntax for writing test cases.
If, on the other hand, you’ve already embraced sound testing practices in your development process, I’ll show you how the Spock paradigm compares to established tools such as JUnit and TestNG (http://testng.org/).
Before getting into the details of using Spock, let’s explore why you need a test framework in the first place. After all, you already test your code manually as part of every coding session, when you make sure that what you coded does what you intended.