When we talk about BDD a “way to automate tests” comes to mind, but actually Behavior Driven Development goes much further. This engineering practice includes techniques and tools that we apply since we raise our product’s requirements (not our tests’ requirements).
Certainly we define requirements in a more “testable” way but our goals when implementing BDD are “Building the right software” and “Building the software right“.
Almost no software that we create is isolated; it’s part of a business strategy and as such, it must be aligned with the business objectives. “Building the right software” is about building the correct software, the one that will meet the user’s expectations and that will solve their problem / need and that is perfectly aligned with the business objectives.
“Building the software right” is about building it well, with the best practices and making sure that it is properly designed and developed, that will give us software that is more reliable and effective.
To know more about what BDD is, how to define requirements and how to use them as documentation, read here
From examples to Gherkin (Given / When / Then)
Let´s suppose we are a bank, and we want to implement the feature “Purchase a foreign currency cash”.
When we have our examples (previously defined in requirement workshops and we map our example mapping), we design our test scenario. Each scenario has steps that we express in Gherkin language: Given, When, Then, And, and But.
Gherkin is a non-technical language that can be read by anyone (as natural language) and that allows us to express behaviors.
The most important steps are:
Given: these are the preconditions for a scenario and preparation of the environment to execute our test.
When: the action to be performed by the user (the action under test).
Then: the expected result. What is the response we expect from the system?
Following our example of the bank and our clients who want to buy foreign currency, we designed this scenario:
Our example with example data in Gherkin language:
Then we write a more generic test, separating the data and converting it into variables that will allow us to run the same test with different data sets:
From Gherkin to source code (scenarios, steps, step definitions)
When we have our tests written in Gherkin, we can convert them into executable specifications (source code). In that way, we can automate our acceptance criteria.
To create these executable specifications, we use:
Page Object Model
Each test scenario is a feature file. Each line of our feature file is a step.
Page Object Model
The Page Object Model is a software design pattern that allows us to group all the selectors and functions (of our system under test) by page.
Step definitions are each and every one of the steps in our feature.
This is our step:
The test runs as many times as we have examples. (in this example, it will run 3 times):
Here you can see and download the source code, and run the tests.
We test behaviors (features and/or bugs), not components nor classes. But this does not mean that we won’t do unit tests. We must see the quality of our products as a “whole”.
“The whole is greater than the sum of its parts”. Test which only test the expected behaviour of our system (products) are not enough to achieve quality.
BDD helps us think and implement quality “Building the right software” and “Building the software right“.
Book BDD in Action. John Ferguson Smart.
Web Zerobank (used to automate tests for this post)