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 "firstname.lastname@example.org" 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.
4 thoughts on “Bad practices when writing your BDD scenarios”
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.
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.
By the example 2, How can i put the same scenario more clear using the same example?
you can use something more abstract without UI elements, for example: When I choose the first picture from the gallery.