Behaviour Driven Development — 1/3 — Overview
First understand the business, then drive the development upon behaviour story telling.
Let’s jump straight in with an example of a Behavioural Test for a cash machine.
The first thing to notice is that the Test is written in plain English.
The second thing to notice is the Test is made of three different sections:
- Given : it’s the arrangement of context state — the starting state
- When : it’s the event, a trigger or when a user does something
- Then : it’s the outcome with the expected results
Once scenarios are ready, the development team can begin their work. Each of the tests will be running — and in the absence of any code — they would fail. The developers start writing code. As more code is written the tests will begin to turn from red to green. When they are all green, the job is done.
This article is part of a serie:
What is BDD ?
Behavioural Tests can be written for a system at any time: before, during or after development.
It can be very difficult to write unit tests for an existing system, but writing behavioural tests for an existing system presents no special difficulty.
The case where the tests are written first is termed Behaviour Driven Development. The plain English nature of context, event and outcomes format that the business people can focus on describing the behaviours that matter to the customer.
When we think about BDD, we think about automated testing, or acceptance automated testing. We can come up with Cucumber, JBehave or some other frameworks. However, doing only acceptance automated testing does not mean BDD. The same idea goes for the case where Behavioural Tests are written during or after development. They aren’t be considered as BDD. There are aspects of BDD that incorporates automated acceptance testing, but BDD is not just about that. There are two parts that are missing: the collaboration and the common language.
BDD is an approach to establish collaboration between the product owner, testers and developers and why not stakeholders. It’s a way to get to find and drive the value in the product we are trying to deliver, rather than having a siloed approach — the traditional way of developing software.
The last piece is the common language. When people are collaborating together, discussion about what matters, and the value of product, they need to use the same language to ensure they understand each other. The common language is about having the same vocabulary, business oriented.
The BDD approach
The BDD approach is based on three major steps : discover, formulate and automate. The first on is quite important as it will drive all the work that follow.
During that first step, we may go through a
tres amigos workshop, or an
Example Mapping workshop, to reach a common understanding at multiple levels and so we can surface uncertainty to deliver software that matters. The stakeholder and product owner are not just telling about something to be done. They are talking about the business needs. So instead of giving directives on what to do, they start a collaborating phase and discuss about what they need, with developers and testers. What is important here is all about starting a discussion between the stakeholder/production owner and developers and testers to bring up the value that the business wants, by asking questions and providing examples that translate business needs. Here we would use a common language, and start using a vocabulary that everyone agree on.
Once everything is clear, we can write down everything, using the agreed vocabulary, then we will have a resulting dictionary which we can refer to during the entire software life cycle. And we would formulate the shared understanding into scenarios, using Gherkin format (Given, When, Then).
At last, we will use the scenarios as input to automate tests. In this article we will see an example with Cucumber implementation to automate scenarios.
tres amigos concept relies on three perspectives - or roles:
The business perspective could be represented by a Stakeholder, Product Owner or a Business Analyst or both. They are to raise to the surface problems we are trying to solve.
The development perspective could be represented by developers, a technical Leader or Architects. They will help to build a solution to solve that problem.
Testers, QA engineers, or sometimes developers will brings in their expertises in testing the product to make sure the quality is met. This workshop would bring to them another angle to tackle functional testing. And they would prevent from things that could possibly happen in an unhappy path?
This discussion session, called an Example Mapping, is based on the
tres amigos concept. People holding different perspectives should collaborate to discuss all the details, to define what to do and agree on how to do it correctly. The end result of such a collaboration results in a clearer description of the work leading to a shared understanding for the team.
A product owner chooses a story and writes the business rules. For each rule, he identifies the data to be used and the expected results. Data should cover all business cases, and the way to achieve that is using examples. From these examples, we can write down scenarios (given, when, then), in an order. They are then used for tests automation in that same order. If there is anything that is not clear enough, regarding the rules or the data, the three parties would ask questions and get answers to make sure they get out of the workshop with concrete and usable scenarios for User Stories. Those scenarios are in fact the acceptance criteria for the user story.
Writing scenarios BRIEFE-ly
From the examples out of the example mapping workshop, we would likely write down many scenarios. Depending on the complexity of the feature or user story, we may end up with several scenarios. However, there are some best practices when it comes to formulate them. The BRIEFE principle may be of help.
- Business vocabulary : use the agreed vocabulary among the
tres amigos. That means anyone can understand. Avoid using terms that others can’t understand.
- Real data — concret : use real data when explaining something, they serve as examples to represent the idea we want to tell.
- Intention : A sample must have only reason to exist. Name it with intention.
- Essential : A sample must help to understand the behaviour described in the scenario. If it does not, it’s useless.
- Focus : There is only one interaction within a scenario.
- Empathy : Samples describe what the user is trying to do, rather than what he does. This helps to understand and maintain. Describe the behaviour rather than prescribing actions. This aims to build empathy for a better user experience.
Perhaps the greatest strength of Behavioural Tests is that they describe in a very direct way the set of the behaviours of what the user can expect from the system. The list behaviours taken together from a “contract” of the complete behaviours that the system is expected to exhibit. If all the Behavioural Tests pass then the contract has been upheld. If any of the tests fail, the contract will be broken.
There is another benefit here that may not be immediately obvious. As a developer, we have a tendency to write too much code or code that does too much or code that includes some degree of supposed “future proofing.” BDD is helping to keep focus on getting the behaviour test to pass. Nothing less — and nothing more.
If all of this sounds too good to be true, it comes with some drawbacks:
- Behaviour Tests tend to be a bit slower to run than unit tests
- When they fail, they only indicate that something went wrong, but may give little or no indication of the root cause
- One thing to avoid, because it is usually misunderstood, is to limiting three amigo discussions to only three people. The three perspectives are about roles, not about people. If there are other stakeholders who are relevant to a particular increment of work, include them in the discussion.
- Also avoid expanding the three amigos discussions to the team. The intent of this practice is to include each necessary perspective with as small a group as possible. The smaller it is, the more efficient it is.