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­i­ty. Thanks to automated tests, you can now find out whether a complex ap­pli­ca­tion fulfills its tasks problem-free at the touch of a button. An in­creas­ing­ly popular technique is behavior-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­sid­ered to be its logical extension. Unlike TDD, however, BDD primarily examines the re­spec­tive software program from the user’s per­spec­tive. This approach promotes a more holistic software design and sim­pli­fies col­lab­o­ra­tion between de­vel­op­ers, quality managers, and customers.

As software re­quire­ments become in­creas­ing­ly 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­i­ty of in­di­vid­ual com­po­nents reliably and promptly discover errors. Test-driven de­vel­op­ment (TDD), whereby de­vel­op­ers 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. Behavior-driven de­vel­op­ment (BDD) makes this possible.

During agile software de­vel­op­ment, all project par­tic­i­pants can define the desired behavior of the ap­pli­ca­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 modeling their own software. BDD therefore promotes col­lab­o­ra­tion and the del­e­ga­tion of re­spon­si­bil­i­ty. 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, behavior-driven de­vel­op­ment is based on the desired behavior of the re­spec­tive software. Thanks to the ubiq­ui­tous language, it’s easy for laypeople to prepare certain behavior de­scrip­tions. The ubiq­ui­tous language comes from domain-driven design (DDD), which – just like BDD – focuses on the ap­pli­ca­tion domains. Both ap­proach­es consider all involved areas in software de­vel­op­ment and bring them together in­de­pen­dent of frame­works, pro­gram­ming languages, or tools. Using a single language makes this possible.

Nev­er­the­less, even behavior-driven de­vel­op­ment is unable to com­plete­ly do without tools and frame­works. That’s because in order for the test cases you define to be trans­lat­ed into ex­e­cutable 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­men­ta­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 hi­er­ar­chi­cal structure you will typically follow in behavior-driven de­vel­op­ment:

• First, conduct a re­quire­ments analysis in which you precisely define the tasks, ob­jec­tives, and func­tion­al­i­ties 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­i­ties, these are then described in the form of pre­de­fined 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 vo­cab­u­lary may vary slightly, although the principle is the same. In­ci­den­tal­ly, these tools are available for the most common pro­gram­ming languages like Java, JavaScript, Python, or Ruby.

Imagine you’d like to develop a user-friendly online store. Once the customer has reg­is­tered 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­for­ma­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, behavior-driven de­vel­op­ment concerns itself with the question “How?”. The par­tic­i­pants wish to know how they can properly test the behavior of the code and not its im­ple­men­ta­tion. By contrast, in the case of a module test, the focus is on de­ter­min­ing whether a single code unit is im­ple­ment­ed correctly. This test procedure therefore deals with the “What?” and is a fast way to find in­di­vid­ual 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­van­tages and dis­ad­van­tages of behavior-driven de­vel­op­ment:

Although you can apply each test procedure in­di­vid­u­al­ly, 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.