What is Behavior Driven Development?
Test Driven Development is the process of using examples to guide the development of each function of your software. In TDD we create our program by working through a loop like this:
So what is Behavior Driven Development?
BDD is somewhat similar and complementary to TDD. However, where TDD focuses on driving the development of the individual functions in
the code, Behavior Driven Development applies a similar process at the level of features. Since features are driven by user needs and users are expressed themselves in natural language rather than the language of code, BDD relies on this natural language to create concrete examples. The image below depicts a typical BDD operation:
To make the examples executable BDD requires a little bit of structure and this structure allows a bridge between the world of programming and the world of natural language requirements. A BDD feature file consists of one or more scenarios. These scenarios are just examples of how the application should behave from the standpoint of a user.
For example you might have a scenario that says:
And another scenario that says:
These examples are written in English, but are still very structured.
The Given portion tells the starting condition for the example, the When line tells what you actually do, and the Then tells what results are expected.
Behind the scenes your BDD framework will match this natural language to code that developers write to actually do those steps, but it is always driven from the natural language. The feature files then become the documentation of the application, but unlike most documentation, if this documentation ever gets out of date, then something will break in your testing stage. Any change made to the software gets verified by every example that was created in this process of documenting the requirements as an executable specification.
None of this is magic.
It is a lot of hard work and requires a lot of discipline across the development team, but the results can be amazing. Not only does BDD streamline the requirements process, but it brings the value of QA to the beginning of development. But a question comes up very often:
Is BDD ==TDD?
The answer is definitively NO. Those seem pretty similar but the key difference is the scope. TDD is a development practice while BDD is a team methodology. The key differences are:
Let’s code
At this stage, we ‘ll just add Cucumber, coroutines and Kluent dependencies to our project.
The following code (written in Gherkin language) explains how to encrypt and decrypt data by using a hybrid crypto system based on Diffie Hellman.
For the rest, we will just create for each scenario (listed above), its steps by choosing the language of our choice. For the example, we will go with Kotlin.
A Step Definition is a Kotlin function with an expression that links it to one or more Gherkin steps. When Cucumber executes a Gherkin step in a scenario, it will look for a matching step definition to execute.
After having generated all the steps, we just have to run all the tests
That’s it. The full code is available on Github .
Below are more resources to enlighten your understanding of BDD and even TDD.
Thank you for reading 😉.
