blog image

What is Behaviour Driven Development?

Behaviour Driven Development (BDD) is a testing methodology that has been around for over 10 years, but is gaining more and more traction as more testing departments are looking for new ways to complement their agile work process’.

The terms BDD and TDD often go hand in hand and many people struggle distinguishing the difference between them.This may be because BDD is in a sense a refinement of or addition to Test Driven Development (TDD) and they are best used together.

In order to fully understand what BDD and TDD are it helps to first discuss unit testing as this is the primary (although not only) type of testing where BDD and TDD are applied.

Unit Testing

Most testers will probably have a good idea of what unit testing involves as it is one of the three most commonly used types of automated testing (along with Integration and Acceptance tests). A unit test is specific in that it only tests a single unit of code, which is usually a function.

A unit test should be isolated from dependencies (such as network and database) and can be run through software designed specifically to create fake, controllable environments.

These two features are the only things that are required for something to be labelled a unit test, and they can be written using any syntax of software that you choose.

The benefits of unit testing include making it easy to make changes to your code without the fear that other parts of the code will break, and also to discover exactly where there may be any defects that are stopping your code working, as you will be able to isolate the exact test that failed.


Understanding how unit testing can be used to improve the testing process makes it easier to explain the Test Driven Development Process, as both lend themselves to more agile testing.

TDD is a process that defines the way that tests are written and run, and has been designed to allow a higher percentage of the tests to be automated and reduce the amount of bugs in tests.

The TDD Process follows these steps:

  1. Write the test
  2. Run the test, along with any other tests you have. (At this stage the test should fail as you have not written any code)
  3. Write the minimum amount of code to make the test pass
  4. Run the Tests
  5. Refactor (Rework or Improve) the code
  6. Repeat

As you will notice, the key difference here to what may have been done before is that the test is written before the code. This is often the the part that can be difficult to learn/ implement.


It is now much simpler to explain what BDD actually is, which is really a set of best practise guideline for writing effective TDD tests (although these guidelines can also be implemented when writing other types of test).

The key thing that BDD changes is the implementation detail in tests. Instead it teaches us to focus on the behaviour that we are testing.

As an example let’s look at the test you might write if you were testing a function that cycles through the letter of the alphabet when you click a button.

A test focusing on implementation might test that after the button is clicked once the value would be B. In terms of the implementation, this would be correct, however it assumes that the original value is A, and so is not testing the general behaviour.

A test written using the BDD principles would test that after the button was clicked, the resulting value would be x+1 (where x=the original value). Therefore what is being tested here is that clicking the button results in the displayed letter being 1 place further along in the alphabet sequence than the one before. Written like this the test should pass no matter what letter it started on.

As well as challenging the focus of tests, BDD also provides guidelines for the language the tests are written in. It  promotes using language and building tests that can be understood by everyone involved in the process to ensure that the correct functions are being built and everyone understands what is required.

The Product Owner, Developer and Tester are involved in building tests in BDD

You may have heard of the term ‘The Three Amigos’ in relation to BDD, and this refers to the concept that when writing tests, the product owner (or product specialist), a developer and a tester should all work together to write the tests. This allows the test to be written from a customers point of view, and aims to reduce any confusion and time taken to correct mistakes.

Achieving BDD

Although there’s no set way to achieve BDD, there are tools that can help. Choosing a testing tool that is designed specifically for BDD can give you a head start in adopting the process and make the transition smoother. We recommend Behave Pro for JIRA for anybody looking to implement BDD into their testing.

Behave Pro is an exploratory testing and BDD tool that uses the BDD process to make agile testing achievable for all teams. For more information on Behave Pro head over to our feature page where you can get in touch with our testing specialists, who can help with all your testing needs!