BDD with Cucumber

If you are used to writing code first and then testing it, then with BDD this approach is not at all appropriate. The strength of the BDD is that it helps lead the development from the design stage of the ToR. For BDD, this is a list of properties (features), which is appropriate to write with the customer.

But most importantly, the project is automatically tested on the same list. The testing tool (in our case it is Cucumber) will methodically go through your list and meticulously check the implementation of each feature.

Development using Cucumber consists of 3 main steps.

1. Description of features of the project in simple human language . And even not necessarily English .
2. Ruby step definition
3. Development cycle: checking features with cuckumber and implementing unsuccessful features with handles.

At the end of this cycle, when all properties pass the cucumber control, we approve with the customer a new list of features and go through the entire cycle again. We do this until we implement (add and verify) all the properties.

1st stage. Features

List

For example, we, as always, are developing a new blog. So write the properties of our blog in a file ./features/blog.features. For each property, we also describe the concepts of Why, Who, and What (In order, A, Should). These are the wishes of BDD, in fact, they do not affect the result, but they help us to more clearly articulate what we want from this feature.

Feature: Post articles
  In order to show trip photos
  A owner
  Should be abble to post article
Feature: Make comments
  In order to contact
  A user
  Should be abble to make comments

Of course, it is not necessary to immediately write out all the properties, enough of those that you intend to implement in the near future.

Scenarios

A property has one or more behavior scenarios. It is in this scenario that testing takes place. Each scenario is described in three categories: Condition (Given), Event (When), Result (Then). If you have several conditions, events or results, then additional ones are registered through And / But.

Feature: Post articles
  In order to show trip photos
  A owner
  Should be abble to post article
  Scenario: Post article by owner
    Given I signed up as owner
    When I write article "About my last nigh trip"
    And text of article is "It was very hard night .."
    And I post article
    Then I should see "Article is created"
  Scenario: Post article by user
    Given I signed up as user
    When I write article "My fantazy"
    And text of article is "..no more"
    And I post article
    Then I should see "You have no access to post articles"

At this stage, we already have a list of features that is understandable to the person and the testing tool. And now you can run:

> cucumber features / blog.features
...
2 scenarios (2 undefined)
12 steps (12 undefined)
0m0.012s
You can implement step definitions for undefined steps with these snippets:
Given / ^ I signed up as owner $ / do
  pending
end
When / ^ I write article "([^ \"] *) "$ / do | arg1 |
  pending
end
When / ^ text of article is "([^ \"] *) "$ / do | arg1 |
  pending
end
When / ^ I post article $ / do
  pending
end
Then / ^ I should see "([^ \"] *) "$ / do | arg1 |
  pending
end

Cucumber tells you what to do next, what actions we need to determine (step definition).

Stage 2. Definition of actions (step definition)

Copy the cucumber hint to /features/step_definitions/blog_steps.rband write down the actions, for example:

    Given / ^ I signed up as (. *) $ / Do | role |
       current_user = User.find_by_role (role)
    end
    When / ^ I write article "([^ \"] *) "$ / do | arg1 |
        aricle = Article.create (: subject => arg1,: user => user)
        same_subject = subject
    end
    When / ^ text of article is "([^ \"] *) "$ / do | arg1 |
      aricle.text = arg1
    end
    When / ^ I post article $ / do
      artricle.save!
    end
    Then / ^ I should see "([^ \"] *) "$ / do | arg1 |
       response.should contain (arg1)
    end

Now we have a list of features ready and their behavior defined.

Stage 3. Testing and development

Run the test:

> cucumber features / blog.features
Feature: Post articles
  In order to show trip photos
  A owner
  Should be abble to post article
  Scenario: Post article by owner # features / blog.features: 6
    Given I signed up as owner # features / step_definitions / blog_steps.rb: 1
      uninitialized constant User (NameError)
      features / blog.features: 7: in `Given I signed up as owner '
    When I write article "About my last nigh trip" # features / step_de

Apparently, cucumber reported that it does not know about any User. In this case, create the user model code.

Run Cucumber again. To this naz, he swears about another error - we are implementing another code in order to fix it, etc. until.

When cucumber passes all the tests, all the code will be implemented. Thus, we have completed the 3rd stage and we can proceed to the further design of the application and the implementation of new features.

If interested, next time I will tell and show how a real application with Cucumber, Shouldaand a wizard is being developed webrat.

PS

Materials:

cukes.info - Website cucumber
nlp.od.ua/behavoir-driven-development - In Russian about BDD
railscasts.com/episodes/155-beginning-with-cucumber - screencast Cucumber for beginners
github.com/thoughtbot/clearance/ tree / master - Clearance has a great example of using cucumber