In this post I'm going to attempt to document some useful guidelines that in my experience has lead to writing cleaner, more maintainable and less flaky features.
Features can contain extra details if it is relevant to the feature
Lets say we are requesting some data from a rest service and we are expecting an xml response. It may be useful for documentation purposes to show this xml response right in the feature file.
Scenario: Data Request
Given I request some data from http://sample.org/data.xml
I should see the xml
'''
<xml>
<data>
hello
</data>
</xml>
'''
Scenarios should not automate the UI
Consider the following code:
Scenario: Invalid email address
When I fill in "Username" with "Username"
And I fill in "Password" with "password123"
And I fill in "Confirm Password" with "password123"
And I fill in "Email Address" with "invalid email address"
And click "Create User"
Then I should see "Please enter a valid email address"
There is a lot of code here that is not relevant to the scenario at all and only serves to automate the browser.
If we remove the details that aren't relevant we get a much more readable scenario:
Scenario: Invalid email address
When I fill in an invalid email address
And click "Create User"
Then I should see "Please enter a valid email address"
Features should only contain information that the user sees
Element ids, CSS and XPath is only relevant to developers and should be kept in the step definitions or removed entirely.
In the following code example we use Capybara to fill in the password text input using the label which links to it using the 'for' attribute.
<label for="password">Password</label>
<input type="text" name="password">
fill_in "Password", :with => "password123"
If you are using SpecFlow instead of Cucumber then Coypu is a very powerful Capybara-like .NET tool.
Scenarios should not be dependant on other scenarios
There should never be a situation where one scenario needs to be run before another scenario.
I've personally seen feature files that had scenarios with names that had number prefixes in order to make sure that they ran in a certain order. This is evil and should never happen.
Never ever ever let this happen:
Scenario: 0TestSetup
Given some data is in the database
Scenario: 1UserNavigatesToProfilePage
Given the user has logged in
When I click Profile
Then I should see the Profile page
Scenario: 2UserChangesTheirPassword
When I enter a new password
And I click Save
Then I should see "Password changed"
Use Background for setup when there's more than one scenario
Remember that whatever is more readable is always better. In the first code sample we only have one scenario so we don't need to DRY up the feature yet, but in the second sample it makes sense to add a Background section.
Scenario: Logged in user visits the user registration page
Given I am logged in
And I visit the user registration page
Then I should be redirected to the home page
Background:
Given I am logged in
Scenario: Logged in user visits the user registration page
And I visit the user registration page
Then I should be redirected to the home page
Scenario: Logged in user visits the logout page
And I visit the logout page
Then I should be redirected to the home page
Feature names are features not processes
Feature names should describe actual features. An example of a bad feature name is "A user registers an account". This feature should probably be called "Registration" or "User Registration".
Don't use multiple 'thens'
Instead of multiple Thens use one Then and follow it up with Ands. The second scenario below is a lot more readable.
Scenario: Registration
When I fill in user details
And click Register
Then I should be redirected to the home page
Then I should see "account created"
Scenario: Registration
When I fill in user details
And click Register
Then I should be redirected to the home page
And I should see "account created"
Your features are your documentation
Relish is a very useful new site that takes all your feature files and displays them in a very readable format.
Why not push all your features up there so that anyone in your team can have access to your feature documentation?
