Skip to content

Agile Testing

Agile Testing

by Stan Taylor

Writing Selenium test steps for cucumber tests

2015/10/16 by Stan

In my current job, I’m responsible for developing a framework for performing UI testing of web and mobile applications with Selenium WebDriver/Appium, using the webdriver.io bindings for node.js Javascript. We have adopted cucumber as the format for defining the tests.

Conventional wisdom regarding UI testing holds that you should always strive to select UI objects by the attribute that is least likely to change. With web UIs, you’ll typically see a hierarchy of preferred selectors as the following:

  1. Element ID
  2. Element name
  3. CSS class(es) associated with the element
  4. Text associated with the element

If you used this strategy with cucumber, you would get tests that looked something like this:

Given I go to the login page
And I enter "johndoe" in the field with id "username"
And I enter "password1" in the field with id "password"
Then the input element with type "submit" should become enabled
And I click the input element with type "submit"

But such steps are counter to the principles of behavior-driven development. The primary purpose of cucumber is that it allows your business owner to write requirements that can also directly serve as tests, and identifiers such as element ID or name are artifacts of implementation details, not part of the basic requirements. Or more simply–your business owner should be able to describe interaction with the application using only what’s visible to them in the UI.

More typically, cucumber steps for the login scenario above would look something like this:

Given I go to the login page
And I enter "johndoe" in the "Username" field
And I enter "password1" in the "Password" field
The the "Log in" button should become enabled
And I click the "Log in" button

Note that the steps use the visible text associated with each element to select the element.

The argument against this approach is: “But whenever your UI text changes–and let’s face it, it often changes–you’ll have to go update every single test!” While this is true, my rebuttal is that it’s a simple global search and replace change, and more importantly, it’s not a change to the code behind the cucumber, only to the cucumber test definitions, which, in my opinion, is a lower risk change than an actual code change.

To be fair, as the number of tests grew, I saw the redundancy between tests as a maintenance risk, so I’ve abstracted out frequently used functions, such as login and navigation, into single steps. Steps like the examples above no longer exists in our codebase. Instead, we have single steps such as:

Given I log in as username "johndoe" and password "password1"

So, now, if the text on our login page changes, we only have to change it in one place.

In my next blog post, I’ll show some of the code behind these steps.

UPDATE: Here is the next blog post.

Post navigation

Previous Post:

Underestimating myself

Next Post:

Words have meanings!

2 Commments

  1. Pingback: Testing Bits – 9/27/15 – 10/3/15 | Testing Curator Blog
  2. Pingback: Upside down automation | Agile Testing

Comments are closed.

About me

My name is Stan Taylor, and I'm a software quality assurance engineer with 20+ years of experience, living in Austin, Texas.

Recent Posts

  • Glad I wasn’t the QA Engineer here!
  • Being a software engineer over age 50
  • It’s not a bug…
  • The evolution of cucumber UI test steps
  • Travel Time to…

Archives

  • November 2019
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • October 2015
  • July 2015
  • January 2015
  • June 2014
  • February 2014
  • April 2013
  • March 2013
  • August 2012
  • May 2012
  • October 2011
  • August 2011
  • June 2011
  • January 2011
  • September 2010
  • May 2010
  • March 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008

Categories

  • Agile
  • Agile Testing
  • Cucumber
  • Distributed Resources
  • Enterprise Agile
  • Odds and Ends
  • Quality Assurance
  • SilkTest
  • Test Automation
  • Uncategorized
  • Unit Testing

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org
© 2019 Agile Testing | WordPress Theme by Superbthemes