Home

The official Cucumber web site has some more marketing blurbs and CukeTV episodes!

Cucumber is a tool that can execute plain-text documents as automated functional tests. Here is an example:

Feature: Search courses
  In order to ensure better utilization of courses
  Potential students should be able to search for courses
  Scenario: Search by topic
    Given there are 240 courses which do not have the topic "biology" 
    And there are 3 courses A,B,C that each have "biology" as one of the topics
    When I search for "biology" 
    Then I should see the following courses:
      | title |
      | A     |
      | B     |
      | C     |

The language that Cucumber understands is called Gherkin. Cucumber targets non technical business analysts, interaction designers, domain experts, testers (for the plain text part) and programmers (for the step definitions, which are written in Ruby).

Cucumber itself is also written in Ruby, but it can be used to “test” code written in Ruby or other languages with the help of some extra tools:

• JRuby and Java
• IronRuby and .NET
• FunFX and Flex
• Web apps in any language – use Cucumber with one of the following:
  • Webrat – Ruby acceptance testing for web applications
  • Watir – Drives IE (Windows only)
  • FireWatir – Drives Firefox on Windows, OSX and GNU/Linux
  • SafariWatir – Drives Safari (OS X only)
  • ChromeWatir – Drives Google Chrome
  • Celerity – Drives a fast headless browser with Javascript support. Examples here
  • Selenium – Runs any browser (any OS)
  • Mechanize – Runs a headless browser (any OS)

(Cucumber’s example directory has examples for some of these)

Cucumber only requires minimal use of Ruby programming, so don’t be afraid to try it out even if the code you’re developing is in a different language. Most programmers should pick up the required Ruby skills and be productive with Cucumber in a few days.

While Cucumber can be thought of as a “testing” tool, the intent of the tool is to support BDD. This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else, and the production code is then written outside-in, to make them pass.

Getting started

There are several ways to get started, depending on the architecture of your application. Take a look at the examples. Each example directory has a Rakefile, and you can run the features in an example directory with

rake features

This will print out the feature files in green. Now go into the code the features describe and deliberately make a bug in the code somewhere. Run the features again and look at the output. Note that the backtrace (stack trace) also shows you the line of the plain text feature that fails.

Developing with Cucumber and BDD

Once you have set up Cucumber in your project you can get down to action.

When you decide you want to add a new feature or fix a bug, start by writing a new feature or scenario that describes how the feature should work. Don’t write any code (yet).

Now run the features again. The one you wrote should have yellow, pending steps – or failing, red ones. (If you don’t get that you’re doing something wrong, or the feature is already implemented).

This is when you start writing code. Start by writing a couple of lines of code to address the failure you got from Cucumber. Run cucumber again. Repeat and rinse until you’re happy with your feature. When you get down to nitty gritty details, drop down one abstraction level and use RSpec, or any Ruby testing framework, to write some specs/tests for your classes. Write the specs first! If you follow this process you have a good guard against brittle, unmaintainable, undocumented code that nobody understands. (Yes, features and specs are documentation too).

If you think this sounds annoying, try it out anyway. You’ll end up writing better, lesser coupled (and less) code this way. Trust me. Work outside-in (the outside being the feature, the inside being the low level code). Do it the BDD way.

Business value and MMF

You should discuss the “In order to” part of the feature and pop the why stack max 5 times (ask why recursively) until you end up with one of the following business values:

• Protect revenue
• Increase revenue
• Manage cost
• Increase brand value
• Making the product remarkable
• Providing more value to your customers

If you’re about to implement a feature that doesn’t support one of those values, chances are you’re about to implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog. Focus on implementing the MMFs (Minimum Marketable Features) that will yield the most value.

[5:08pm] Luis_Byclosure: I'm having problems applying the "5 Why" rule, to the feature 
                         "login" (imagine an application like youtube)
[5:08pm] Luis_Byclosure: how do you explain the business value of the feature "login"?
[5:09pm] Luis_Byclosure: In order to be recognized among other people, I want to login 
                         in the application (?)
[5:09pm] Luis_Byclosure: why do I want to be recognized among other people?
[5:11pm] aslakhellesoy:  Why do people have to log in?
[5:12pm] Luis_Byclosure: I dunno... why? 
[5:12pm] aslakhellesoy:  I'm asking you
[5:13pm] aslakhellesoy:  Why have you decided login is needed?
[5:13pm] Luis_Byclosure: identify users
[5:14pm] aslakhellesoy:  Why do you have to identify users?
[5:14pm] Luis_Byclosure: maybe because people like to know who is 
                         publishing what
[5:15pm] aslakhellesoy:  Why would anyone want to know who's publishing what?
[5:17pm] Luis_Byclosure: because if people feel that that content belongs 
                         to someone, then the content is trustworthy
[5:17pm] aslakhellesoy:  Why does content have to appear trustworthy?
[5:20pm] Luis_Byclosure: Trustworthy makes people interested in the content and 
                         consequently in the website
[5:20pm] Luis_Byclosure: Why do I want to get people interested in the website?
[5:20pm] aslakhellesoy:  :-)
[5:21pm] aslakhellesoy:  Are you selling something there? Or is it just for fun?
[5:21pm] Luis_Byclosure: Because more traffic means more money in ads
[5:21pm] aslakhellesoy:  There you go!
[5:22pm] Luis_Byclosure: Why do I want to get more money in ads? Because I want to increase 
                         de revenues.
[5:22pm] Luis_Byclosure: And this is the end, right?
[5:23pm] aslakhellesoy:  In order to drive more people to the website and earn more admoney, 
                         authors should have to login, 
                         so that the content can be displayed with the author and appear 
                         more trustworthy.
[5:23pm] aslakhellesoy:  Does that make any sense?
[5:25pm] Luis_Byclosure: Yes, I think so
[5:26pm] aslakhellesoy:  It's easier when you have someone clueless (like me) to ask the 
                         stupid why questions
[5:26pm] aslakhellesoy:  Now I know why you want login 
[5:26pm] Luis_Byclosure: but it is difficult to find the reason for everything
[5:26pm] aslakhellesoy:  And if I was the customer I am in better shape to prioritise this 
                         feature among others
[5:29pm] Luis_Byclosure: true!

Outcomes and bottom-up scenarios.

The value provided by a system is what you can get out of it – not what you put into it (Chris Matts said that). Just like the value is expressed at the top of a feature (In order to…), the value should be in the steps of a scenarios too, more precisely in the Then steps.

When you’re writing a new scenario, I recommend you start with the formulation of the desired outcome. Write the Then steps first. Then write the When step to discover the action/operation and finally write the Given steps that need to be in place in order for the When/Then to make sense.

Read more about Given-When-Then.