Let me start by saying that Cucumber is easily the coolest piece of software I've ever used. As far as Holy Grails go, I can't imagine anything better than this perfect merger of clients and developers,tests and documentation. When I moved from Rails 2 to Rails 3, it was Cucumber that made the transition as painless as one could hope.
For lack of a better way to put it, Cucumber makes me feel proud to be a Ruby developer. And if you are in a situation where your non-technical client has a deep involvement with your feature sets, stop reading now - Cucumber is the perfect tool for you.
But for all its greatness, I feel that Cucumber winds up miscast, like putting Natalie Portman in a porn film. In this series of posts I will discuss my personal move from Cucumber to Steak (and beyond...).
My introduction to Cucumber was via Thoughtbot's Clearance gem and it gave me a great starting point. The tests were clear, easy to build upon, and gave me a great way to start acceptance testing within a sane environment. And my non-ruby-developer friends were all floored by the power of Cucumber.
However as time went on, I started to feel like Cucumber was solving a problem which didn't exist. And worse, it was creating several new problems.
First of all, even socially adept developers spend more time reading and writing code than dealing with human beings. And our inclinations/abilities reflect this. The day you enjoy communicating with people and reading/writing documentation more than coding, you should quit programming.
So Cucumber makes developers do what is secondary to their nature. And it throws into the mix two mappings that you need to always keep in your brain. From plain English to a regex, and then from a regex to Ruby. When all the while, there is something that works just as well with no mappings at all - Ruby.
The Ruby language is tremendously readable and as close to English as it gets. And when you couple it with RSpec and a homemade DSL, it is easy enough to build legible tests such as:
As far as I am concerned, that is both plain English and pure Ruby, so as a developer it excites me. Probably your non-technical clients won't be able to read it, but that's fine. Nobody who has their car's engine rebuilt wants to check out the shop manual - they just want it to work.
So as developers, why are we dumbing down our tests for clients who either don't exist or don't read our tests? Cucumber can be the worst example of the YAGNI principle. And for all the awesomeness of having a test tool spit out prettified documentation, I don't usually read it.
Look at this another way. Some people believe that comments as a whole are a code smell, and often an indication that something like the Extract Method refactoring is called for. As a parallel, I'd argue that if you want your testing tool to spit out documentation, perhaps your tests are insufficiently self-documenting.
Another problem that I had with cucumber was that, as a developer, I found it having an identity crisis. Look at this example from the cucumber wiki:
This is confusing to me. Why is it so specific? If the goal was making clients read your tests, wouldn't it be easier for them to read:
This seems more clear to me, and some people do write Cucumber this way. I did, and since after a while you have so many steps built up, you tend to have less than one new step per-scenario. Which is cool in terms of conciseness. But it still doesn't do it for me, because that client/regex/ruby disjunct is still there. For me a big example of things going too far, is the unavoidable practice of calling steps from within steps. It works great, but since the step definition block is the land of Ruby, it always bothers me to leave it for the land of regexes and string interpolation.
Maybe then my problem isn't so much a flaw with Cucumber, but that I love Ruby too much. In my next article I will talk about my prettified DSL for acceptance testing with RSpec.