What is behaviour driven development? Behaviour-driven development (BDD) is an evolutionary technique that helps software developers to create better quality programs by focusing on the behaviour (or features) of a system under construction.

One example of how BDD can be applied to software is TDD which stands for Test Driven Development where tests are written before the code. The example below shows this in action.

In a TDD process, you write a test before the code is written to make sure the tests fail, then you write the code for the feature and then once all tests pass you will refactor your code. This whole process is called Red-Green-Refactor and is a very common way to use TDD.

What is behaviour driven development? Does it involve only developers?

With BDD it also includes something called acceptance criteria. These are things like specifications and non-functional requirements or sometimes even examples of how a feature should work. One big difference between BDD and TDD is that BDD allows for more collaboration with other team members such as project owners, business analysts etc.

In other words, BDD is used to make sure that your code not only works but also works well with the team and stakeholders, so you get buy-in from them when building new solutions or features.

Is it easy to switch from a different methodology to BDD?

As with any new development methodology, there is a learning curve involved. In order to harness the full benefits of BDD, this learning curve must be conquered first. Some people who have used traditional agile methods such as TDD and Scrum found it difficult to adapt to writing so much documentation. This is because they are already thinking in the same way and so don’t even need to write any new documentation. They can just reuse what they were previously doing.

A way in which BDD has been applied beyond software development is through the use of acceptance testing. It is a way of testing software that as the name suggests tests to make sure that it meets acceptance criteria. Acceptance criteria can be put down in a document or even be examples of what the users want from the system.

Conclusion

The idea with BDD is that your team spends a lot of time thinking about the functionality of the system and then writing out those requirements in User stories, Use cases or user scenarios. Once the requirements have been written, it can then be tested to make sure that it meets these acceptance criteria and is ready for release.

Read an interesting article on how to choose a test automation tool.