BDD and Cucumber

Behavior Driven Development (BDD) to me is like we develop the software to achieve some specific behaviors that are derived from customers requirements. It is popular because it clears the goal of development: what you need to do is to make the software behaves as required.

There are generally three steps.

1. engineers and customers work together to create user stories. They often look like this:

Feature: Add a movie to Rotten Potatoes

  As a movie fan [a kind of stakeholder]

  So that I can share a movie with other movie fans [achieve some goals]

  I want to add a movie to Rotten Potatoes database [by doing some tasks]

They focus on "what could the software do" but with more details. Actually there is a theory called SMART user story that requires participants to create stories that are Specific, Measurable, Achievable, Relevant and Timeboxed.

2. expand user stories into steps that involve several scenarios and lo-fi UIs. The former is specific to the Cucumber, the BDD tool used by Rails. In Cucumber, an user story is defined by several steps like:

Feature: User can manually add movie

Scenario: Add a movie

  Given I am on the RottenPotatoes home page

  When I follow "Add new movie"

  Then I should be on the Create New Movie page

  When I fill in "Title" with "Men In Black"

  And I select "PG-13" from "Rating"

  And I press "Save Changes"

  Then I should be on the RottenPotatoes home page

  And I should see "Men In Black"

A feature could behave differently in different scenarios, that is why we could have multiple scenarios in one feature. Lo-fi UIs are sketches to achieve two goals: (1). to obtain a look for this feature; (2). to connect this feature with others.

3. Iterate cucumber and improve your code until it accepts all steps.

For the course SaaS, it actually teaches us BDD before TDD, result in that we are building features based on what we code instead of building code based on features. Therefore in this post, I only write about how cucumber works.

Cucumber is actually a gem that needs to be included in your Rails project. By including that we will have a new directory called features, in which we store .feature files. Features directory has a subfolder called step_definitions, in which we store .rb files that define every step we will take. The step definition uses regular expression to catch a step in feature file, and then define the acton to test this step.

Some notes:

1. At the first time to execute cucumber, you have to create a test database by rake db:test:prepare. Cucumber runs in the test environment of Rails.

2. To reuse and compress the code, when different scenarios have several steps the same, they could be extracted into a new section called Background under that feature.

3. In Cucumber you are not dealing with objects and data you created for production or development environment anymore. Every time it runs it generates data it needs.

4. To debug in cucumber, set debugger flag as usual in rb files. In debug mode, use page.body, which is the HTML page generated by Capybara (the test tool used by Cucumber) to check your data instead of model object.