This is the first in a series of short posts explaining what Cucumber is and isn’t. Used correctly, Cucumber can be a tool for great good. Used poorly, it’s an invitation to disaster. KNOW YOUR TOOLS.
I’ve been cuking for nearly as long as cuking has been possible. I’ve made every mistake there is to make. I’ve recently given a talk on Cucumber, and will be giving another one along somewhat similar lines at LA Ruby Conf with co-conspirator Robbie Clutton.
Your Feature and your UI are two different things
One of the quickest ways to go wrong with Cucumber is to attempt to describe your user interface in words. I’ve seen a lot of features that read something like this:
Scenario: Send a valid tweet When I click inside the tweet text input Then it should expand to a text area And I should see photo, location, and tweet buttons And the tweet button should be disabled and greyed out When I type the following text into the text area: "short tweet" Then I should see the "Tweet" button enable itself When I click the tweet button Then a new div should appear in my timeline letting me know a new tweet is available When I click on the anchor tag within that div Then I should see the timeline expand with my new tweet automatically without a page refresh
Words can’t do a UX justice. They are far too inefficient. And worse, any attempt to describe a user interface with words will inevitably obscure the underlying state machine of your feature. It will hide behind the laborious language of the user interface. This scenario should have been written like this:
Scenario: Send a valid tweet Given I have authenticated When I submit a tweet 140 characters or less Then my followers should receive that tweet And I should see my tweet in my timeline
This feature captures the actual underlying state machine behind sending a tweet:
- You have to be logged in
- Your tweet has to be less than 140 characters
- Anyone following you will automatically receive your tweet
- You will see your tweet posted in your timeline
It also discusses the feature in the language of the application’s domain, not in the language of a particular user interface.
So what do you do about the UI? Turns out, you can create *visuals* to describe your User Interface. A picture truly is worth a thousand words. There’s lots of great ways to work out the visual UX of your application, including:
- Pen and Paper
- Storyboarding paper prototypes with your iPhone
Cucumber is a tool for working out the state machine that is your application, and living with the complexity that the state machine entails. It’s a way to structure the conversation you have to have with your product owner. It’s a way to capture all of the concrete examples and edge cases behind a feature.
It’s not a replacement for a designer. It’s not a replacement for wireframes. It’s not a replacement for story boards. It’s a tool for collaboration; if a feature file isn’t the result of a conversation, you are doing it wrong.