How To Add Visual Testing To Your BDD Tests

By: Dave Haeffner

If you’re new to Behavior Driven Development (BDD) tooling (e.g., Cucumber) it may not be obvious how scenarios you’ve specified (using the Gherkin syntax) translates into test automation. If that’s the case, then adding visual testing to the mix might be a challenge as well.

A Solution
By using the built-in functionality of our BDD tool of choice, we can easily generate step definitions for our scenarios and add in test execution with a third-party provider like Applitools (for visual testing) and Sauce Labs (for access to additional browsers/devices).

NOTE: In order to do BDD well don’t start with automation. You should focus on communication instead. This way everyone on the team (both business and tech alike) have a shared understanding of what needs to be done and what is actually being done. There are loads of great write-ups to help guide you on this. Pieces like “Step Away From The Tools” by Liz Keogh (link) and Specification Workshops from “Bridging The Communication Gap” by Gojko Adzic (link). An Example

For this example, let’s use Cucumber to step through automating the login of a website. Scenarios for valid and invalid users would look something like this:
# filename: features/login.feature
Feature: Login
Scenario: Valid User
Given a user with valid credentials
When they log in
Then they will have access to secure portions of the site
Scenario: Invalid User
Given a user with invalid credentials
When they log in
Then they will not gain access to secure portions of the site

Gherkin scenarios are plain text files that end in .feature. And they live in a directory called features.

Inside of the features directory, there are some additional folders we’ll want to use (e.g., step_definitions and support).

+-- features
¦ +-- login.feature
¦ +-- step_definitions
¦ +-- support


When we save the feature file and run it (e.g., cucumber from the command-line), Cucumber will see if there are any step definitions that match. If there aren’t, it will provide us with some code to get us started.

You can implement step definitions for undefined steps with these snippets:

Given(/^a user with valid credentials$/) do
pending # express the regexp above with the code you wish you had
end

When(/^they log in$/) do
pending # express the regexp above with the code you wish you had
end

Then(/^they will have access to secure portions of the site$/) do
pending # express the regexp above with the code you wish you had
end

Given(/^a user with invalid credentials$/) do
pending # express the regexp above with the code you wish you had
end

Then(/^they will not gain access to secure portions of the site$/) do
pending # express the regexp above with the code you wish you had
end

We can copy this outputted code and paste it into a new file — login.rb in the step_definitions directory.

This is where we’ll place our test actions (e.g., Selenium commands, assertions, etc.). But before we do that, we’ll need to take care of setting up and tearing down our Selenium session.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/