Chapter 1. Introducing the Spock testing framework

This chapter covers

• Introducing Spock
• Bird’s-eye view of the testing process
• Using Groovy to test Java
• Understanding Spock’s place in the testing world

We live in the computer revolution. We’ve reached the point where computers are so commonplace that most of us carry a pocket-sized one all the time: a mobile phone. Mobile phones can now perform real-time face recognition, something that used to require a mainframe or computer cluster. At the same time, access to cheap and “always-on” internet services has created a communication layer that surrounds us.

As we enjoy the benefits of computerized services in our daily lives, our expectations are also changing. We expect information to be always available. Errors and unexpected behavior in a favorite software service leave us frustrated. E-commerce is on the rise, and all brands fight for customer loyalty as we turn to the internet for our shopping needs. Once I ordered a single chair from a well-known furniture company, and my credit card was charged three times the amount shown on the product page because of a computer error. Naturally, I never bought anything from that online shop again.

These high expectations of error-free software create even more pressure on developers if the “user” of the software is an organization, another company, or even a government agency. Software errors can result in loss of time/money/brand loyalty and, more important, loss of trust in the software.

If you’re a software developer at any level, you know that writing programming code is only half of software creation. Testing the programming code is also essential in order to verify its correctness. Software problems (more commonly known as bugs) have a detrimental effect on the reliability of an application. A continuous goal of software development is the detection of bugs before the software is shipped or deployed to production.

A bug/issue that reaches production code can have a profound effect, depending on the type of software. For example, if your software is a mobile application for tracking daily intake of calories, you can sleep easily each night knowing that any issues found by users will only inconvenience them, and in the worst case they’ll delete your application from their mobile phones (if they get really angry about the problems). But if, for example, you’re writing software that manages hotel reservations, consequences are more serious. Critical issues will result in customer anger, brand damage for the hotel, and probable future financial losses.

On the extreme end of the spectrum, consider the severity of consequences for issues with the following:

• Software that controls hospital equipment
• Software that runs on a nuclear reactor
• Software that tracks enemy ballistic missiles and retaliates with its own defensive missiles (my favorite example)

How will you sleep at night if you’re not sure these applications are thoroughly tested before reaching production status?