Cucumber is my tool of choice for Specification by Example. I like Cucumber for three reasons:
- The specifications are written in plain English
- The supporting tools are very mature
- The step definitions are clean
Plain English specifications
Technically the specifications are written in a Domain Specific Language called Gherkin, and you can have Gherkin in any language you want. But as far as my team are concerned, and the product owners in particular, it is plain English. Here is an example:
Scenario: A Diary Entry must have a Slug Given the "West" Diary is empty When I add a Diary Entry with no Slug Then the "West" Diary is still empty And a "Slug is mandatory" error occurs
Cucumber has been around a while and comes from the Ruby community who are passionate about automated testing. So not surprisingly the tool support for Cucumber is very mature. For example you can use either Webrat or Capybara to get headless browser testing (fast) but the capability to interface with Selenium if you want to drive the UI through an actual browser. Great.
Clean step definitions
Ruby has another massive impact on Cucumber. Cucumber’s step definitions are written in Ruby. The Ruby language is very clean. So the step definitions are clean.
Both the clean nature of the code and the brilliant tool support mean that using Cucumber is easy for development teams to use.
Cucumber is great. Check out the Cukes website and the Cucumber book (Wynne & Hellesøy, 2012).
Unfortunately not everybody can use Cucumber. Luckily there are Cucumber-esk variants for other environments and languages. For example, my last two teams have been .NET so we’ve used SpecFlow. Unfortunately the tool support in .NET isn’t very mature and, being C#.NET the step definitions are pretty horrible to read compared the Ruby alternatives. Deep sigh. But at least the specifications are in plain English and executable. It is worth it just for that.
This post is part of a series on Specification by Example.
Wynne, M. & Hellesøy, A. (2012). The Cucumber Book: Behaviour-Driven Development for Testers and Developers. Pragmatic Bookshelf.