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 power of BDD is that it helps lead the development from the design stage of the TOR. For BDD, this is a list of properties (features) that is appropriate to write with the customer.

But the most important thing is that according to the same list there is an automatic testing of the project. The testing tool (in our case, this is Cucumber) will systematically follow your list and will meticulously verify the implementation of each feature.

Development using Cucumber consists of 3 main stages.

1. Description of the project features in simple human language . And even optional English .
2. Definition of actions (step definition) in Ruby
3. Development cycle: verification of features by a cuckemer and implementation of untested features with handles.

Upon completion of this cycle, when all properties pass cucumber control, we approve a new feature list with the customer and re-run the entire cycle. We do this until we realize (add and check) all the properties.
')

1st stage. Features

List

For example, we, as always, are developing a new blog. So we write the properties of our blog in the file ./features/blog.features . For each property, we also describe the concepts of Why, Who and What (In order, A, Should). These are BDD wishes, in fact they do not affect the result, but they help us to formulate more clearly 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 those that you intend to implement in the near future.

Scenarios

A property has one or more behaviors. It is under this scenario that the 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 is prescribed 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"
     "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 the person and the testing tool can understand. 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. Determination of actions (step definition)

Copy the cucumber hint in /features/step_definitions/blog_steps.rb and prescribe 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 is 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 the 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 model code User.

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

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

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

PS

Materials:

cukes.info - cucumber website
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