BDD: the missing link between requirements and code

Well, at this moment you might be wondering if this gap between requirements and code isn't what we generally call software engineering. In both agile and traditional approaches, like waterfall, we can perform the phases of analysis and design precisely so that the requirements are fully met by the application (dictated by the code). And that is true!

But let's get to practice. The requirements are collected from the client, all doubts are clarified, and all business terms are explained. Then, after some time, we present the first version to the client so they can perform their tests. And this process can repeat several times, especially in agile development methodologies. And this is where things start to get out of control.

After each software delivery, the client will probably contact you with several change suggestions. Either because the business rules have changed or because the requirements were not well defined. And this is more common than you might imagine!

At this point, the client will be heard, perhaps the design will be redone, and here we go again to code a change in the application. And what happens to the requirements documents collected at the beginning of the project? Be honest!

If your answer is that they are forgotten and outdated, and no longer hold any meaning, BDD comes to the rescue!

With Behavior Driven Development (BDD), specifications are written through examples. And they are written in a language completely independent of technology. We use client-world terms without any technicality from the computing context. And what's most interesting: the specifications are directly linked to functional tests! This way, if the example changes, the respective test should also change, and the test that used to pass will now show an error.

We write the specifications using the Given, When, Then format (there are many other terms that will be explained in future posts):

• Given: determines the context or the preconditions necessary to use a certain functionality
• When: usually indicates an action taken by the user, an interaction with the software.
• Then: describes the expected result after the action.

Example:

Scenario: User with no open tickets
Given the user has no open tickets
And the user accesses the open tickets section
Then the system should display a message informing that there are no open tickets for them        

After the client approves the specification, we can proceed to writing the tests. The tests are strongly connected to this specification, so if the former changes, the test will fail.

Then("the system should display a message informing that there are no open tickets for them", () => {
    // teste here
});        

Don't get hung up on the terms used in the test. What matters is the strong connection between the specification and the test. If the example changes, the test must also be modified! This is how we want to keep the requirements fully aligned with the software's behavior.

Well, this is my first post about BDD, and I intend to bring many more soon, always delving a little deeper.

#BDD