Behaviour-driven development – a simple explainer

In the past, quality management would spend weeks checking a finished software program for its functionality. Thanks to automated tests, you can now find out whether a complex application fulfils its tasks problem-free at the touch of a button. An increasingly popular technique is behaviour-driven development – or BDD for short. This form of agile software development emerged from test-driven development (TDD) and is considered to be its logical extension. Unlike TDD, however, BDD primarily examines the respective software program from the user’s perspective. This approach promotes a more holistic software design and simplifies collaboration between developers, quality managers, and customers.

What is behaviour-driven development?

As software requirements become increasingly complex, a growing number of quality and test management methods are being developed. These are necessary in order to check the functionality of individual components reliably and promptly discover errors. Test-driven development (TDD), wherebydevelopers prepare suitable unit tests or system tests in addition to creating the software, has been around for some time now. However, when designing a software program, it can often be a good idea not only to involve programmers, but also team members or stakeholders without technical coding skills. Behaviour-driven development (BDD) makes this possible.

During agile software development, all project participants can define the desired behaviour of the application before the programmer creates the source code. This process involves descriptions composed in a language that is easy for people to understand. This means that the customer can play an active role in modelling their own software. BDD therefore promotes collaboration and the delegation of responsibility. When this type of software development is used properly, you can avoid misunderstandings from the outset and create a higher-quality end product.

How exactly does behaviour-driven development work?

As the name suggests, behaviour-driven development is based on the desired behaviour of the respective software. Thanks to the ubiquitous language, it’s easy for laypeople to prepare certain behaviour descriptions. The ubiquitous language comes from domain-driven design (DDD), which – just like BDD – focuses on the application domains. Both approaches consider all involved areas in software development and bring them together independent of frameworks, programming languages, or tools. Using a single language makes this possible.

Nevertheless, even behaviour-driven development is unable to completely do without tools and frameworks. That’s because in order for the test cases you define to be translated into executable code, you need to follow a few rules. Descriptions in BDD are not composed as free-flowing text, for example. Using BDD tools like JBehave, Cucumber, or Behat, you can follow a set structure that enables correct implementation. It’s much easier to work with these tools than learn a conventional programming language. Below you’ll find the hierarchical structure you will typically follow in behaviour-driven development:

  • First, conduct a requirements analysis in which you precisely define the tasks, objectives, and functionalities of the software. Ask yourself or the customer what the software should be able to do.
  • After you have identified all the functionalities, these are then described in the form of predefined scenarios. Try to think of all the possible scenarios during which the software should respond with a certain answer.
  • Next, specify the expected answer for each scenario in a ‘Given-When-Then’ plan. ‘Given’ describes the software before the test, ‘When’ the action during the test, and ‘Then’ the state of the software after the text.

Depending on which BDD tool you use, the vocabulary may vary slightly, although the principle is the same. Incidentally, these tools are available for the most common programming languages like Java, JavaScript, Python, or Ruby.

Behaviour-driven development: a case example

Imagine you’d like to develop a user-friendly online store. Once the customer has registered on your store, their user data should be saved. In this way, they can log in again as often as they wish, without having to re-enter their personal information. In the popular Gherkin language used in the BDD tool Cucumber, the correct syntax would be as follows:

Functionality: An existing customer should be able to log into their user account with their access data
	Scenario: Customer enters the correct access data for the login process
		Given I have a valid user account
		And I am on the login webpage
		When I enter my email address in the email field
		And I enter my associated password in the password field
		And I click on the login button
		Then I should be automatically logged in

The above example shows that you can use the addition ‘And’ to list multiple conditions and make your test cases more complex.

How does BDD differ from other test procedures?

When testing software, behaviour-driven development concerns itself with the question ‘How?’. The participants wish to know how they can properly test the behaviour of the code and not its implementation. By contrast, in the case of a module test, the focus is on determining whether a single code unit is implemented correctly. This test procedure therefore deals with the ‘What?’ and is a fast way to find individual bugs. The question ‘When?’ is answered by test-driven development which is about the process of executing tests. This process can also include module tests or other test methods.

Note

Besides module tests, there are also integration and function tests. These are somewhat more complex, since they deal with the interplay of various system parts and the overall functionality of a software program.

In the table below, you’ll find a brief summary of the advantages and disadvantages of behaviour-driven development:

Advantages Disadvantages
Ideal for beginners thanks to the ubiquitous language, with no previous knowledge required Poorly written specifications make the work of developers more difficult
Better communication between developers, stakeholders, and quality managers Involving multiple parties leads to longer development times
Test cases serve as living documentation and can easily be adjusted Switching to BDD workflows involves greater effort than with legacy code
Focus lies on end users and the user-friendliness of the software  

Although you can apply each test procedure individually, the quality of your software will improve considerably when you combine multiple test methods. In the case of BDD, you define the best approach when writing tests, while TDD provides high test coverage.


Wait! We’ve got something for you!
Get your .co.uk domain for just £1/1st year.

Enter the web address of your choice in the search bar to check its availability.
12 month for £1/1st year
then £10/year