Home > QA, Test and Automation Stuffs > Bad practices when writing your BDD scenarios

Bad practices when writing your BDD scenarios

I usually write about the best practices to follow when writing your BDD scenarios. This time I will do different and write some examples that I found of how to not write your BDD scenarios.

 Example 1 – Too many steps :

  Scenario: Valid data entered
    Given a user exists
    When I visit the details access page
    And I fill in email with "test@email.com"
    And I select "read only" from "Permissions"
    And I fill in "Valid until" with "2010-03-01"
    And I press "Grant access"
    Then I should see "Access granted till 2010-03-01."
    And I should be on the details page

 

 Example 2  – UI elements dependency:

   Scenario: Adding a picture 
     Given I go to the Home page 
     When I click the Add picture button 
     And I click on the drop down "Gallery"
     And I click on the first image
     Then I should see the image added on the home page

 

 Example 3 – Excessive use of tables :

   Scenario: Adding a new data user 
     Given I am on  user details page
     When I select an existent user
     And I send some new user data
     |name |age|country|language|address |telephone|
     |James|20 |england|english |street 1|123456789|
     |Chris|30 |spain  |spanish |street 2|987654321|
     Then I should see the correct previous registered data
     |gender  |married|smoke|
     |male    |true   |true |
     |male    |false  |false|

 

 Example 4  – Code and data structure:

   Scenario: Include attachment
     Given I go to the Attachments page 
     When I click the Add attachment button with css "#attachment-button"
     And I click on the first csv file with class ".file .csv"
     Then I should see the file attached with the id ".attachment"

 

  • Write declarative scenarios.
  • Write at a higher level of abstraction, instead of being concerned with clicking widgets on a page. Surfacing UI concerns on a feature can make it fragile to ordinary design changes.
  • Try to stick to having not more than 5 steps per scenario. It’s easier to read.
  • Avoid code or data structure like xpath selectors, css class, regex in your scenario.

 

Advertisements
  1. May 2, 2017 at 8:27 am

    the first one is too generic..
    if you use the cucumber also as a part of you documentation, then your steps should be explicit.. so therefore you many need some more steps.

    • May 2, 2017 at 7:19 pm

      Hi Leonardo, I don’t agree with you. The first one is still a bad practice. I use BDD as part of documentation as well, but I never exceed more than 5 steps for each scenario, otherwise it is not readable.

  2. Felipe luz
    September 27, 2017 at 12:56 am

    By the example 2, How can i put the same scenario more clear using the same example?

    • September 28, 2017 at 7:22 am

      you can use something more abstract without UI elements, for example: When I choose the first picture from the gallery.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: