Behavior Driven Development

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.

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), whereby developers 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.

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.

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:

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

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.

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

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.