Thursday, June 25, 2015

Gherkin Reuse

Unfortunately there is no silver bullet for automation.  As with every tool there are both positives and negatives, to get the most from an automation tool we need to accentuate the positives and mitigate the negatives.  With gherkin based tests we can reuse the same language and stories for multiple tests, mitigating the problem of maintaining stories.

Gherkin best practices state that where not directly testing the GUI tests should be UI agnostic.  UI agnostic tests require less frequent changes and are often shorter and easier to maintain.

UI agnostic example:

Given the user has an open account
When they close their account
Then the account has a status of closed

UI specific example:

Given the user has an open account
And the user is on the account status page
When they click close account
And select yes from the prompt
Then the user is taken to the account status page
And the accounts status is displayed as closed

Although fictitious this example is similar to what I've noticed regularly testers who are new to gherkin writing.  The UI specific test:

  • Will require more maintenance as the test is bound to the UI with any dialog/button name changes needing to be reflected in the test.
  • Longer in length making test sets more difficult to quickly read through.
  • Difficult to move to another UI/platform.  For example if we were going to run this test on a mobile device the action click is not as relevant and should possibly be replaced by tap.


In the latest framework I've developed, tags on a test cause the test to be run multiple times on different platforms.  For example a test tagged @soap, @iOS, @chrome would be run as a soap test, on a ios device and on the chrome browser.  In the UI agnostic test we can use (scope binded steps) to have the same story but be executed in the appropriate way for the SUT.

Additionally for one of the latest project we have the same execution platform but different authentication methods.  We were able to set the tests to run by default using both authentication methods with only one underlying method changing between the two test executions.

One of the complaints often registered against gherkin tests is that maintaining the stories is time consuming/difficult.  By having good practices/documentation/training in story creation and reusing the tests across different executions we can continue to gain the benefits from using a gherkin testing whilst mitigating some of the difficulties.

No comments:

Post a Comment