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.