Skip to content

Instantly share code, notes, and snippets.

@alindeman
Created December 7, 2012 17:26
Show Gist options
  • Save alindeman/4234855 to your computer and use it in GitHub Desktop.
Save alindeman/4234855 to your computer and use it in GitHub Desktop.
On Fri, Dec 7, 2012 at 10:10 AM, tim ruffles <timruffles@googlemail.com> wrote:
> Just ignore any mention of Cucumber (unless you're working with the mythical .feature file writing/reading client).
I agree that a newbie should ignore cucumber. I teach my pairing clients the same way.
But this is a meme that just annoys me, because it's BS. And not only that, the most prominent people repeating it *tend* to be people who are out of touch with client work. (Not referring to you here, but to some of the louder voices behind the "mythical client" meme.) There absolutely are clients who write cucumber, or something very close to cucumber, or who sit with a developer and collaborate to write an English description of their needs which can then serve as an automated acceptance test.
But the bigger problem with this meme is that it's a strawman. Cucumber, and the BDD ideas it comes out of, are about *establishing common language among ALL stakeholders*. This may not mean between client and developer. I worked on one team where one of the QA people would write his tickets in gherkin-style syntax. We freaking *loved* that guy. Because he used the "As a... I want to... so that... " and "given... when... then..." format, his tickets always had sufficient context and could often be pasted straight into a feature file. And they helped us understand not just the technical problem, but the perspective of the nontechnical user running into the problem.
One of the problems that Cucmber/Gherkin addresses is that programmers almost always overestimate their own ability to get out of "programmer brain". I've often seen the statement "we'll just write specs in RSpec in domain language". But almost invariably, the actual specs that come out of the process are deeply "code-ey" and get bogged down in CSS selectors and making sure background jobs get run and digging around inside deeply nested (and often poorly-named) object models. Gherkin is another whack to the back of the programmer mentality, trying to jump you out of the "programmer brain" mindset and say, with apologies to Sam Jackson, "DOMAIN LANGUAGE MOTHER****ER, DO YOU SPEAK IT?"
Of course, sometimes even Cucumber specs read like Ruby. What can I say, you can lead a horse to water...
For more about Cucumber as a tool for establishing common language throughout a team, I highly recommend this article: http://blog.mattwynne.net/2012/11/02/is-cucumber-just-a-scam/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment