Behavior Driven De­vel­op­ment

In the past, quality man­age­ment would spend weeks checking a finished software program for its func­tion­al­ity. Thanks to automated tests, you can now find out whether a complex ap­plic­a­tion fulfils its tasks problem-free at the touch of a button. An in­creas­ingly popular technique is behaviour-driven de­vel­op­ment – or BDD for short. This form of agile software de­vel­op­ment emerged from test-driven de­vel­op­ment (TDD) and is con­sidered to be its logical extension. Unlike TDD, however, BDD primarily examines the re­spect­ive software program from the user’s per­spect­ive. This approach promotes a more holistic software design and sim­pli­fies col­lab­or­a­tion between de­velopers, quality managers, and customers.

As software re­quire­ments become in­creas­ingly complex, a growing number of quality and test man­age­ment methods are being developed. These are necessary in order to check the func­tion­al­ity of in­di­vidu­al com­pon­ents reliably and promptly discover errors. Test-driven de­vel­op­ment (TDD), whereby de­velopers 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 pro­gram­mers, but also team members or stake­hold­ers without technical coding skills. Behaviour-driven de­vel­op­ment (BDD) makes this possible.

During agile software de­vel­op­ment, all project par­ti­cipants can define the desired behaviour of the ap­plic­a­tion before the pro­gram­mer creates the source code. This process involves de­scrip­tions composed in a language that is easy for people to un­der­stand. This means that the customer can play an active role in modelling their own software. BDD therefore promotes col­lab­or­a­tion and the del­eg­a­tion of re­spons­ib­il­ity. When this type of software de­vel­op­ment is used properly, you can avoid mis­un­der­stand­ings from the outset and create a higher-quality end product.

As the name suggests, behaviour-driven de­vel­op­ment is based on the desired behaviour of the re­spect­ive software. Thanks to the ubi­quit­ous language, it’s easy for laypeople to prepare certain behaviour de­scrip­tions. The ubi­quit­ous language comes from domain-driven design (DDD), which – just like BDD – focuses on the ap­plic­a­tion domains. Both ap­proaches consider all involved areas in software de­vel­op­ment and bring them together in­de­pend­ent of frame­works, pro­gram­ming languages, or tools. Using a single language makes this possible.

Nev­er­the­less, even behaviour-driven de­vel­op­ment is unable to com­pletely do without tools and frame­works. That’s because in order for the test cases you define to be trans­lated into ex­ecut­able code, you need to follow a few rules. De­scrip­tions 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 im­ple­ment­a­tion. It’s much easier to work with these tools than learn a con­ven­tion­al pro­gram­ming language. Below you’ll find the hier­arch­ic­al structure you will typically follow in behaviour-driven de­vel­op­ment:

• First, conduct a re­quire­ments analysis in which you precisely define the tasks, ob­ject­ives, and func­tion­al­it­ies of the software. Ask yourself or the customer what the software should be able to do.
• After you have iden­ti­fied all the func­tion­al­it­ies, these are then described in the form of pre­defined 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 vocab­u­lary may vary slightly, although the principle is the same. In­cid­ent­ally, these tools are available for the most common pro­gram­ming languages like Java, JavaS­cript, Python, or Ruby.

Imagine you’d like to develop a user-friendly online store. Once the customer has re­gistered 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 in­form­a­tion. 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 con­di­tions and make your test cases more complex.

When testing software, behaviour-driven de­vel­op­ment concerns itself with the question ‘How?’. The par­ti­cipants wish to know how they can properly test the behaviour of the code and not its im­ple­ment­a­tion. By contrast, in the case of a module test, the focus is on de­term­in­ing whether a single code unit is im­ple­men­ted correctly. This test procedure therefore deals with the ‘What?’ and is a fast way to find in­di­vidu­al bugs. The question ‘When?’ is answered by test-driven de­vel­op­ment 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 ad­vant­ages and dis­ad­vant­ages of behaviour-driven de­vel­op­ment:

Although you can apply each test procedure in­di­vidu­ally, the quality of your software will improve con­sid­er­ably 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.