BDD: Cucumber / Gherkin – Preventing feature file proliferation

GENERIC GHERKIN SCENARIO

Feature: App log in

Scenario: User can log in with valid credentials
Given the user is on the log in screen
When the user attempts to log in with valid credentials
Then the user can log in

Note that there’s no detail in here about hard coded credentials, which fields credentials should go in or which buttons should get tapped etc . It’s a behavioural test and currently holds true for all our apps where there is a log facility.

Step definitions for App1

step(“the user is on the log in screen”) {
Launch app
Assert user is on log in screen
}

step(“the user attempts to log in with valid credentials”) {
Fill in these fields to log into App1
Tap login button
}

step(“the user can log in”) {
Assert user is now on correct post login landing page
}

Step definitions for App2

step(“the user is on the log in screen”) {
Launch app
Assert user is on log in screen
}

step(“the user attempts to log in with valid credentials”) {
Fill a whole set of different fields to log into App2
Tap login button
}

step(“the user can log in”) {
Assert user is now on correct post login landing page
}

  1. Gherkin is fine as it helps understand the user story and adds acceptance criteria.
    The definition of acceptance criteria through gherkin is a key feature. Otherwise it is hard to track test coverage and test ability. Especially in Agile Teams Gherkin and BDD is helpful as User Story’s tend to have too much room for interpretation.
  2. You could use Scenario Outlines to define the Test Environments to handle duplicated Scenarios.
  3. Write one Test for login with a paramterized target environment.
    Data driven parts (data tables) or scenario outlines are the only way to handle this in Gherkin itself.

Reference: https://club.ministryoftesting.com/t/cucumber-gherkin-preventing-feature-file-proliferation/23596/4

Leave a Reply