BDD in Test Automation

This is an introduction to Behavioral Driven Development. I used C# with Specflow to achieve BDD in selenium. So I will add my understanding here on the Concepts of BDD.

Why Use BDD?

Now, the common scenario is that a Business Analysts are not always a technical person and has a problem in understanding the automation test structure, where tests are just the method specifications or method calls.

Similarly keeping the TDD approach, we again have the same problem that the tests are a methods call.

In both the approaches, all BA’s must have is and experience with the programming language syntax else there is no way of understanding it.

Thanks to Dan North!! He solved the problem for us by introducing Jbehave and Rbehave for Java and Ruby respectively. Here he introduced the simple text language syntax(known as Gherkin), making things understandable. So Gherkins hides the test implementation code behind a plain text(Now supports multiple languages) and let anyone understand what this test does.

Following is the Gherkin syntax :-

Feature: Guess the word

  # The first example has two steps
  Scenario: Maker starts a game
    When the Maker starts a game
    Then the Maker waits for a Breaker to join

  # The second example has three steps
  Scenario: Breaker joins a game
    Given the Maker has started a game with the word "silky"
    When the Breaker joins the Maker's game
    Then the Breaker must guess a word with 5 characters

So if your audience is a non technical people, yo may choose to develop your automation framework in BDD.

Exploring Gherkins

So let us use following gherkin for our understanding of what is what :-

Gherkin Syntax (Feature file)

So Gherkins has a small set of keywords or concepts which are following :

1. Feature
2. Background
3. Scenario
4. Given
5. When
6. Then
7. And
8. But
9. Examples
10. Scenario Outline

All these can be defined in the file with a “.feature” extension file which are referred here as feature files.

Features is a unique name of collection of scenarios, through which one can easily understand what test this feature file will contain. so the syntax goes as :-

Feature: Name of the feature
Description of feature

Feature comes up with the line below them to describe the feature briefly.

Background is a place to define a common code where you want these list of steps to be executed before every Scenario in the same feature. this is analogous to Setup() or BeforeTest() methods widely used in selenium or TestNG.

In the Gherkin Syntax shared above, user will have to navigate to any website, for all the scenario under the feature file, so instead of writing it again and again, we prefer to write that precondition once for all.

Scenario is where we write the actual steps of operations to be performed. Scenario comes up with a unique test case title which is written after “Scenario: This is the test title”. No two same scenarios can be present anywhere in the feature files. These scenarios has steps which starts with Given, When, And, Then and But.

Given some initial context,
When an event occurs,
Then ensure some outcomes.

This means, ‘Starting with the initial context, when a particular event happens, we know what the outcomes should be.’

Thus, the example shows the expected behavior of the system. The examples are used to illustrate different scenarios of the system.

And/But If you have successive Given’s, When’s, or Then’s, you could write:

Example: Multiple Givens
  Given one thing
  Given another thing
  Given yet another thing
  When I open my eyes
  Then I should see something
  Then I shouldn't see something else

Or, you could make the example more fluidly structured by replacing the successive Given’s, When’s, or Then’s with And’s and But’s:

Example: Multiple Givens
  Given one thing
  And another thing
  And yet another thing
  When I open my eyes
  Then I should see something
  But I shouldn't see something else

So “And” and “But” helps us increase the readability of the feature file and are actually Given , When and Then. If they are used after a When , they will be a when in the definitions.

Scenario Outline is useful in a place where we want to execute same steps with different set of data. For example, I want to test login functionality for two different user. So the BDD will be:

Scenario Outline example

This will execute twice once for each row in the examples table taking values in each row one by one. So if we have 10 users, we can go ahead for test them all just by adding required information into the examples table.

What Next?

Install any Gherkin Parser, like Specflow, Cucumbur, Jbehave, Rbehave etc. and explore the working of Gherkins to enhance BDD approach.