Link: http://rubysource.com/matt-wynne-on-using-cucumber/
Wynne is the co-author (with Aslak Hellesøy) of Pragmatic's The Cucumber Book. In this interview by Pat Shaughnessy, he explains a bit about what Cucumber is for and how it can help teams deliver good software:
Q: So do you view Cucumber as a pair or group programming tool?
Wynne: I view it as a team communication or collaboration tool really. So by playing the game, forcing yourselves to try to describe what you want the software to do, together, what you end up doing is surfacing all the things that you haven’t actually figured out yet and all the things that you’re not really sure about. This is what Dan North calls deliberate discovery.
If I put a team in a room and I say: “Right OK – tell me about your user stories. Right. Tell me about the acceptance criteria for that user story. Right. Let’s write down the scenario together that describes how somebody might use that piece of functionality.” And they have a great, big argument! That’s what happens. They all have slightly different ways they want to describe it, slightly different words they want to use. And that argument is really, really important because what that is exposing is all of the different mental models all of the different people on the team have got. By exposing those differences and getting them out into the open, you can start to bridge the gaps between people’s different mental models. The earlier you do that on a project, the smoother the whole thing goes.
After DHH wrote his "testing like the TSA" post last week — in which one of his "seven don'ts of testing" was "don't use Cucumber" — I've been meaning to write something about how we (sometimes) use Cucumber at Typekit, and why some developers (like DHH) are so dead-set against it.
I think one source of the anti-Cucumber sentiment is the romantic notion of the solo hacker-cowboy, who invents whole new systems and disrupts entire industries alone in his dorm room at four in the morning. Even if you believe in the value of teams and teamwork, there's still a big cultural sense that programming is something this hacker-cowboy type ought to be able to do solo with a minimum of fuss, and Cucumber is simply not optimized for that. That's because, as Wynne says, it's not strictly a testing tool — it's a tool for coordinating tests, written in your programming language of choice, with the higher-level goals and intents of the work, as expressed in natural language.
One of Cucumber's greatest strengths is in encouraging "ubiquitous language": if everyone on the team can agree on a single written definition of what the product should do, and all make a deliberate effort to use the same language to talk about the work, there's much less potential for costly misunderstanding, and the project goes more smoothly. And by pairing the English-language specs with programming-language step definitions, you're forced to map the broader team's shared understanding of what the product should do with the developers' understanding of what the product actually does.
In other words, Cucumber's value is relative to the effort you're willing to put into breaking down what an ex-coworker once called "knowledge silos" and getting everybody — developers, designers, business analysts, project managers — talking to each other at the same table. Part of that is seeing code for what it is: not anything magical, rather just another way of expressing the same things everyone else is saying in a format the computer will understand. Ruby is just punch cards in a friendlier format.
That's not to say you're a horrible person who's doing it wrong if you're not using Cucumber. If you're working on a story that's really straightforward, or on a purely technical task that no one but developers has a stake in, there's probably no reason to write Cucumber tests for it. Other testing tools still provide ways to map code to human language, not the least of which is how you choose to name individual tests, methods, or whatever. If everyone on a project or task can read Ruby (or whatever language you're using), and your tests are sane and readable by everyone on the team, then yeah, the added overhead of writing and maintaining Cucumber scenarios and steps will probably be wasted effort.
That said, even as a solo developer, I've found Cucumber extremely useful for developing complicated features by working backward from business requirements. For example, last year I wrote a new version of our revenue-sharing algorithm by starting from Cucumber specs written in collaboration with our CFO, who made sure they accurately described the requirements, then implementing the feature with plain Ruby and raw SQL queries, layering on additional layers of abstraction until I'd built a library we could plug into our main application. Here again, the key difference between this and other projects was the need for collaboration. Cucumber allowed coders and non-coders to speak the same language, helping me make fewer mistakes and thereby deliver a complicated feature really quickly.
You might be a horrible person, however, if you say Cucumber's pointless because it's not optimized for the hacker-cowboy use case. There's a lot to be said for the joy of hacking away at a problem, and chasing the high of solving a hard problem all by yourself, but there's also a lot of value in stepping back, slowing down, and working with others to make sure you're solving the right thing the right way. Your process is just another tool for doing your work. It's important to understand your tools