Ten tips for writing better Cucumber steps
January 1st, 2012

Martin Englund posted an open question to the Puppet mailing list a few days ago asking how people are verifying their systems are built as expected: When you write code, you always use unit testing & integration testing to verify that the application is working as expected, but why don't we use that when we install a system? What are you using to verify that your system is correctly configured and behaves the way you want? He linked to a blog post demonstrating how he was verifying his machines using Cucumber. Coincidentally, about a week earlier at Devopsdays in Gent, I was talking to Felix Kronlage and Bernd Ahlers from bytemine about doing similar things through testing SSH and mail delivery with cucumber-nagios. It's pretty cool people are thinking about doing BDD/TDD with infrastructure, and it's even cooler that the tools are at the point where doing this is actually possible. When doing software testing, your testing tool is normally separate from the language and libraries you're building the software with (but almost always written in the same language). When testing your infrastructure, I think it makes perfect sense to apply this practice.

This document is a step-by-step guide for Cucumber, a tool that is quickly becoming the weapon of choice for many agile teams when it comes to functional test automation, creating executable specifications and building a living documentation.

Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented.

Gherkin serves two purposes – documentation and automated tests. The third is a bonus feature – when it yells in red it’s talking to you, telling you what code you should write.

Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language.

There are a few conventions.

Single Gherkin source file contains a description of a single feature.
Source files have .feature extension.

minitest provides a complete suite of testing facilities supporting TDD, BDD, mocking, and benchmarking.

Tom Sulston explains how to manage systems with Cucumber and Puppet based on BDD principles, including practical tricks and pitfalls. The session demoes using those tools.