The Real Value of Cucumber

In the article, Why I Recommend Against Using Cucumber, the author Jason Swett, stipulates some problems with how he sees Cucumber being used incorrectly, and that even if used correctly, he posits that Cucumber has a “small negative value.” While people’s testing practice may vary, and there is more than one way to skin a cat, based on our experience using Cucumber at MojoTech on many Ruby projects, I felt the need to offer a rebuttal because Mr. Swett’s piece does not address the primary benefit of Cucumber when disparaging its merits.

I concur wholeheartedly with Mr. Swett’s breakdown of a poorly written Cucumber scenario.

Given a user exists with email "test@example.com" and password "mypassword"
And I visit "/sign_in"
And I fill in the "Email" field with "test@example.com"
And I fill in the "Password" field with "mypassword"
And I click "Sign In"
And I visit "/user/edit"
And I fill in the "First Name" field with "John"
And I fill in the "Last Name" field with "Smith"
And I fill in the "Age" field with "30"
And I click "Save"
And I visit "/profile"
Then I should see "John Smith, 30"

As he aptly demonstrates, this is merely instructions for the browser which then have to be duplicated in step definition code. It is essentially the same work twice, once in Gherkin, and once in step definitions. Worse, if your interface or process changes, you’ve now built two things that are coupled to the implementation instead of the just one.

He moves on to show a well-written Cucumber:

Given I am signed in
And I provide my name and age details
Then I should see those details on my profile page

With this example, he cites two flaws. First there is no clarity over Capybara, and second, the steps are poorly organized.

Addressing the second and easier point, code can always be poorly organized. So you can do poorly with either approach. But I’ll concede the point that you have to force order on your step implementations and that without guidelines or experience, you’re likely to do it poorly until you get the hang of it.

The first flaw he cites though is fundamental to our different valuation of Cucumber. If you accept the point that the main value of the Gherkin is to dictate how to drive your browser, then it is indeed a little more work than Capybara and thus a little less value.

Where Gherkin syntax shines is that it is a well written specification that as a byproduct can be “run.” If I take the Gherkin style prose and show it to a business expert/product owner, or just want to map out what I plan to accomplish, text is orders of magnitude more efficient in terms of speed than writing code and depending on the Capybara code, may be that much more readable by a non technical stakeholder to confirm assumptions. Even to check your own assumptions, it is faster to clarify in text and then to code. I think this is the real value writing a specification first over writing code first.

If you can’t realize that value for whatever reason, then using Cucumber is indeed a minor extra overhead. But our experience at MojoTech has shown:

Clarity in thinking is far easier to achieve with language rather than code.

I think that is the value that was overlooked in the article.

P.S. If this is the type of healthy discussion you’d like to have with your colleagues, we’re looking for software developers like you to join our team.