I finally finished reading the “Cucumber book”. I started reading this book a while ago.
Even before I finished reading it I was already convinced of the benefits of human readable executable specifications and started lobbying for its use in a project at work. I succeeded (partially).
What this means is that we can write the tests in a human readable way. Natural language is used, with very few keywords mixed in the middle.
Cucumber then converts the human readable text into steps to drive the system. These steps are typically written in ruby and need to communicate with the system in some way (command line, web service, etc), but it is also possible to write them in other languages. Particularly interesting to me: you can write them directly in C++, with the cucumber-cpp project.
Keeping the actual test definitions free of implementation details allows the tests can be shared not just between testers and programmers, but also with the product owners (sometimes referred to as the stake holders).
The goal is to have each tests laser focused on what functionality you are describing, and pushing the implementation and test setup details into other layers.
In fact, what I enjoyed most of the book was not the actual tool itself (I am unable to use Cucumber at work currently), nor the technical details of how to effectively use Cucumber, but the emphasis on test clarity.
In a way, it reminded me of how I felt when I first read Clean Code.
I couldn’t convince our team to switch the test tool of choice (at least for the time being). We are sticking with Robot Framework, and I was pleasingly surprised to find out it has support for the Cucumber syntax for defining tests: Gherkin.
All in all, I highly recommend reading this book, even if you don’t know ruby or don’t see the need for these kinds of tests. You might just change your mind while reading the book.