Writing good tests is hard. Writing good specification is even harder. On my current project we treat test code with the same care we treat production code (which should be the norm on all projects), but we could still improve the readability, reliability and maintainability of our test suite.

With this in mind, Fifty Quick Ideas to Improve Your Tests by Gojko Adzic, David Evans and Tom Roden was the perfect choice for our book reading club. I’ve previously read Gojko’s Specification by Example, which really helped me better understand BDD and how to use it in practice, so I had high hopes for this book.

Structure

The 50 ideas are split into four categories, Generating Test Ideas, Designing Good Checks, Improving Testability and Managing Large Test Suites. Each chapter contains one idea, the context in which it can be applied, its key benefits and some quick tips on how to make it work. Most of the chapters contain concrete, practical examples so it’s easy to see how each idea could be put in practice.

In Generating Test Ideas, the authors show us how to improve the process through which we define tests. This part had a lot of new information for me and it provided new approaches on defining acceptance criteria and engaging business stakeholders (which I think is often overlooked). The ideas touch many aspects of testing: quality, exploratory testing, getting past the unknown unknowns through deliberate discovery, measuring quality attributes (Nonfunctional Requirements), managing cross-cutting concerns, working with other teams and how to improve collaboration during specification workshops.

Since the focus of this part is to generate test ideas, it is less technical than the rest of the book, so it can easily be read by non-technical people too.

Designing Good Checks gives very good advice on how to design your tests, with a strong focus on acceptance criteria. We were already aware of and applying many of the tips in this section, but there still was a good number of possible solutions to problems we are currently facing. In particular, the fact that a specification might be overly complex not because the feature is inherently complex, but because of: misalignment between the business model and the technical model, specification described at the wrong level of abstraction or focusing too much on test scripts instead of key examples. Looking for solutions to these underlying problems might lead to breakthroughs in design, so we should always question the complexity of a specification.

One useful suggestion that is probably hard to get right is balancing the three most important attributes of a specification: conciseness (are you writing good specifications?), completeness (are you testing enough?) and coherence (is the documentation clear and easy to understand for business peoples as well as technical people?).

This part of the book ends with one advice that most people starting out with BDD don’t follow: Don’t automate manual tests.

Improving Testability is all about making your system easier to test and the tests more reliable, easier to manage and maintain. It has a few good pointers on the most common testing pain points:

• how to design good checks in an asynchronous system (like an event-driven SOA solution)
• how to handle time bound events
• how to handle UI tests (we need to minimize UI interactions – no surprise here)
• how to structure your automation framework code and how to split business decisions, workflows and technical interactions in separate layers, each with its own responsability and reason to change.

The last part, Managing Large Test Suites, contains suggestions on how to structure large tests suites and how to make a test self explanatory and improve its readability and reliability.

Biggest Takeaways

For me, the biggest takeaway was how to improve the process through which we generate test ideas. The first part contains quick tips that can be applied in refinement meetings, three amigos session or specification workshops. One example of such an idea is to start with always/never: in order to get past the ‘unknown unknowns‘ phase when you first discuss a feature, you can kick start the session with things that should always happen or should never happen. This can provide a good base for discussion and a first set of examples. Also, using absolute terms can lead to more interesting questions and scenarios.

I’ve also picked up some ideas on how to handle overly complex scenarios and how to make a specification easier to read, understand and maintain.

Improvements

I think that the book delivered what it promised – 50 ideas that could be put immediately in practice. Most of the ideas weren’t ground breaking, although I did have a couple of a-ha moments.

Conclusion

This is the first book I’ve read from Fifty Quick Ideas book series and I wasn’t disappointed. This book is perfect for a book reading club, since it is short, easy to read and provides concrete examples that can spark a lot of discussions. During the sessions, the entire team talked about how we are applying some of the principles or how we can use some of the ideas to improve our test code. If you’re looking for a quick read that provides fresh ideas on how to improve your tests, this is a good choice.