BDD stands for behaviour driven development. TDD stands for test driven development.
Both BDD and TDD refer to the methods of software development employed by your engineering team. There are broadly 2 mainstream approaches to development: test driven development is one and behaviour driven development is the other.
Test driven development
Test driven development is primarily concerned with the principle of unit testing. That is, testing specific, individual units of code.
Your product’s codebase is made up of small units of code which are responsible for specific parts of your application. Testing individual units of code is known as ‘unit testing’ and you may have heard your engineering team refer to unit tests.
There are several stages and principles to be followed in test driven development. These stages and principles are summarised here:
- All tests are written before the code
- Write a test
- Run all tests to check that the new test fails
- Write the code
- Re-run the tests
- Refactor the code if necessary
- Re-run the tests
The primary focus in test driven development is to ensure that the unit tests pass and that the ‘build’ is green. What’s the build? Well, every time your engineering team add a new feature or story, they are adding it to ‘the build’. This works like adding a new frame to a movie. The build – the entire movie – is comprised of individual, specific frames and when a new frame is added, test are run to ensure the entire movie plays as it should.
If everything passes, this is typically known as the build being ‘green’. If the tests do not pass, the build is ‘red’ – something has broken and it needs to be fixed before your engineering team can proceed.
The term ‘code coverage’ refers to the amount of your codebase which is covered by these types of tests. Your engineers, CTO and other technical leaders in your organisation will refer to code coverage targets as an aspirational target to achieve.
Benefits of TDD
- Short debugging time / effort – When a unit test fails, you’ll know exactly what specifically has failed.
- Safety net – tests become a safety net for the team – this can increase morale between engineers and bolster confidence in your engineering team.
- Less bugs – more unit tests can often reduce the number of defects
However, focusing exclusively on the code itself i.e. the technical aspects of a system, disregards the human, or behaviouralaspect of your application.
Behaviour driven development
Behaviour driven development is different to test driven development. The 2 approaches are not necessarily mutually exclusive and are often used together.
The primary goal of behaviour driven development is to solve the problem of communication between the business (including the product manager), the engineering team and the machines.
If you think about a recent feature that’s been pushed to production, by the time a feature is deployed to production it will have moved through numerous stages, each with their own filters and interpretations. This set of chinese whispers is known as the cost of translation. The aim of behaviour driven development is to reduce the cost of translation.
Broadly speaking, BDD is meant to eliminate many of the issues that TDD introduces. BDD tests use a more verbose language so that they can be read almost like you would read a sentence. The ability to read tests like a sentence is a cognitive shift in how you think about your tests.
The argument is that if your engineers can read their tests fluidly, they will write better and more comprehensive tests. It’s often said that BDD is to help design the software, not test it and that TDD is meant to test it. Either way, BDD principles can help you and your team shift your mindset towards the behaviour of your product so that testing isn’t from a purely technical perspective.
Principles of BDD
- BDD encourages simple languages to be used across teams, known as ubiquitous languages.
- The simple and easy to use language should be used in the way the tests themselves are written, so that in theory, a business person can read a test and understand what it is testing.
- Tests are often written from the customer’s point of view; the focus is on the customers and the users who are interacting with the product
Benefits of BDD
- Simple language – the straightforward language is usable/understandable, not only by domain experts, but also by every member of the team.
- Focus – BDD helps teams focus on a product’s behavioral elements rather than focusing on testing the technical implementation in isolation through individual units. This subtle, but important shift, means that everyone is focused on what the behaviour of the product should be.
- Using Scenarios – BDD is designed to speed up the development process. Everyone involved in development relies upon the same scenarios. Scenarios are requirements, acceptance criteria, test cases, and test scripts all in one; there is no need to write any other artifact.
- Efficiency – BDD frameworks make it easy to turn scenarios into automated tests. The steps are already given by the scenarios – the automation engineer simply needs to write a method/function to perform each step’s operations.
How to write BDD scenarios
Your first question is probably ‘what are BDD scenarios?’. That’s a fair question!
A BDD scenario is a written description of your product’s behavior from one or more users’ perspectives. Scenarios are designed to reduce the cost of translation and make it easier for your engineers to understand the requirements and for your QA (if you have one) to test it properly.
Using BDD scenarios means requirements and tests can be combined into 1 specification. In some cases, the scenarios that are written can then be easily converted into automated tests. BDD scenarios tend to follow a specific format. The format is fairly straight forward, and with a little practice you’ll be able to write your own.
In order to explain how BDD and scenarios work in practice, let’s take a look at the example of a user signing up to LinkedIn.
Example – signing up for a LinkedIn account
Here’s a basic BDD scenario which describes the LinkedIn signup process:
Scenario 1: User successfully creates a LinkedIn Account
- GIVEN John is on the LinkedIn Registration page
- WHEN he enters all required registration fields
- THEN a LinkedIn account is created
Let’s take a look at what’s going on here.
The first thing you’ll notice is the header ‘Scenario 1: user successfully creates a LinkedIn Account’. All written BDD scenarios should be given a header which accurately describes the scenario you’re interested in. You may have a few scenarios to assist your engineers / QA team and without headers things can get messy.
The second thing you’ll notice is the use of 3 words: GIVEN, WHEN, THEN. They don’t necessarily need to be in capital letters but, in a similar way to SQL, sometimes keywords are made more clear if they’re in caps.
GIVEN, WHEN, THEN
In its simplest format, there are 3 key elements in any BDD scenario:GIVEN (describing the context)
WHEN (describing the action)
THEN (describing the outcome)
These 3 elements help to describe the behaviour of the system using context, actions and outcomes. If you have more than one or you require more information than this, you can add them with AND.
Using ANDs
When you require more information in a scenario, an ‘AND’ can be used after any of the descriptors:GIVEN (context),
AND (further context),
WHEN (action/event),
AND (further action/event),
THEN (outcome)
AND (further outcome)
Make sense?
OK, let’s revisit our LinkedIn registration scenario and flesh it out in more detail with a few ANDs.GIVEN John is on LinkedIn Registration page
WHEN he enters all the required registration information
AND he hits ‘join now’
THEN his LinkedIn account is created
AND he is directed to the profile creation page
AND his confirmation email is sent
How do BDD scenarios work with user stories?
Your BDD scenarios should form part of 1 specification. This includes both the user story and the scenarios. So, for example, if you’re writing a user story in Jira or some other beloved backlog management tool you could structure your specification in Jira in the following order:
- User story – start with the user story describing the requirements from a user’s perspective
- BDD scenarios – then include your scenarios describing the behaviour of the system to assist with testing
A user story has a slightly different structure to your BDD. Your user story should comprise the following:
As an X
I can / want Y
So that Z
Using our LinkedIn example:As a new user (John), I can register a new account on the homepage so that I can access LinkedIn.
Your BDD scenarios would then follow:Scenario 1: User successfully creates a LinkedIn Account
GIVEN John is on LinkedIn Registration page
WHEN he enters all the required registration information
AND he hits ‘join now’
THEN his LinkedIn account is created
AND he is directed to the profile creation page
AND his confirmation email is sent
If you have multiple scenarios, you’d add these after Scenario 1 in a sequence.
When should BDD scenarios be used?
BDD scenarios are not necessarily mandatory across all of your product specifications. If they were you’d spend most of your life writing BDD scenarios which would clearly be very unpleasant.
BDD scenarios are best suited to specifications where you think there is a likelihood that the requirements may be misunderstood without them or that a more thorough testing approach needs to be adopted. If you’re working on a small color change, text change or a technical chore / bug, there will clearly be no case for using BDD scenarios as this would be a waste of everyone’s time.
It may be that you as a team decide to write them for all major new feature stories or that you only focus on a specific type of specification. BDD scenarios can assist you in your development process but as with all things product, you and your team should decide on what works best for you.