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

    Also popular now: