BDD — How, Who & When

Introduction

Firstly, let’s introduce BDD and give a definition for it so we all are starting at the same place.

Behavior Driven Design were born from TDD and way over technical implementation, which we will discuss later, directly implies communication between the development team, QA, and non-technical participants.

Mainly it plays the role of a fluent implementation of user interface automation tests driven by a non-technical description of the user interaction with the software and the development team indications and collaboration.

In this context emerges the necessity of specifying a clear language so communication is possible with no misunderstood. This problem could be solved through specifications, which offer a place where this three-party can synchronize following a simple schema.

Features should be sliced into scenarios matching the schema of “Given, When, Then”. Let’s give an example.

Given I am at “home page”
When I click at the “first card”
Then I go to it’s “card details”.

You also can configure scenarios like that:

Given I am at “home page”
When I click at “Account” button
And I click at “My Account” in the dropdown
Then I go to “my account” details.

With this you can configure complex scenarios to implement some complex user actions. Giving it a second look you can notice that language and schema are flexible enough so anyone can read a scenario and know what it’s talking about. It should offer a place of meeting for a fluent and clear conversation between our three agents.

Getting it to the technical field. Solutions like Cucumber for Java or Specflow for .NET are great ways to attack that space and get a place to fluently transform schemas into code.

Implemented through Selenium, these tests verse about a recreation of user interaction with the software. So, our intention is to keep it as real as we can, because you want to ensure users can do whatever they are supposed to can be doing.

Keywords

Given that presentation. Let’s go over some keywords. We had been talking about translating users’ interactions with the product into mandatory requirements for the development. A common fight with Test-Driven Development. The Specifications are the support where the development team, QA, and non-technical participants can be understood with clarity. Through the technical field, Specflow and Cucumber together with Selenium play the role of turning the Specifications into a recreation of user interaction with the product.

What to beware of?

At this point, you should be noticing that we implicitly had been walking through the “How” and the “Who”, but nothing has been said of the “When”.

Well. To talk about the “When”, we should go under the hood. Perhaps getting user interaction like a mandatory requirement in the development from the start is a valuable card, but, really possible?

Development environments are development environments, which means they’re in constant change. No matter which technique or work schema you use, you should expect changes.

Selenium is a quite sensible tool, anyone one who had used it can tell. Problems like charge times, development bugs, deployments, service instability will be weight over the tests development.

Trying to express complex functionality with a simple language sometimes ends up with lots of texts that hardly can be rewritten to match a pattern. Remembering it should be turned into code, you want the text to be as standardized as possible.

Focusing on the specifications. Too complex specifications, too many features, or focusing on things that will probably be in change will become stones over your roof. You should beware of them. If a specification is too complex, given it’s a sensible environment it will have a great rate of fail.

Also, needs to be over the table the next fact. BDD, like TDD, implies a slower development, given it puts quality over the rush. Not taking those facts into account could probably lead to a fragile structure in the implementation forcing developers to make not the best decisions but the fastest due to avoid high impact changes.

How to manage this?

Nevertheless, there are ways to minimize and manage the impact. Unsurprisingly, those ways start with planning. From my experience, I can tell there are two ways of implementing BDD avoiding, at least, most of the time.

First one. Taking BDD from the start of the project, defining responsibility clearly, and choosing carefully the technologies to use. If your development would be in some JavaScript framework or library, requesting from an API, you would probably choose to implement this in JavaScript also. This way you would have all the utilities needed to manage problems that for sure will appear.

Getting a plan where, from the start, you standardize and document all the decision making, creating a structure or pattern where next time the team is facing the same problem would no need to think the best way to proceed. Also, it leads to a fluent implementation and no need to rework or readjust the previous developments, at least, minimizes the need. Most important, it makes predictable the state tests will be when new specifications come up, what, in other scenarios would be a headache.

Second one. Getting the same team to write front-end and tests. One of the biggest problems doing tests like that is the mismatch between non-technical members’ expectations (represented by specifications) and technical implementation. Makes no sense to involve people that have no knowledge of behavior to make behavior-driven development. How would you know if you’re doing great if you don’t know what you are doing? Here is where the problems start. Making some developers only take care of tests, in a development environment will lead to lots of misunderstood: not knowing if the test or development is wrong, inability to negotiate with non-technical members about how to solve a problem or modify a test because of lack of knowledge of technical implementations are some of the problem derived from this strategy.

Furthermore, non-technical members probably know less than desired or even nothing of test principles, what or how to test correctly, leading to non-sense tests. It’s normal, technical members are there to bring that knowledge, and is expected from them to guide the three-party to useful and sense-making tests. Negotiating, with a plan and knowledge about implementation technical details should save a lot of time and problems.

Conclusion

To sum up, BDD is a powerful software development process when well implemented. On the other hand, not taking into account the complexity and costs in time and effort required could take team into a rush where — like any software project — the product will not achieve quality standards and will not be usable and scalable. This problems could be solved by planning, defining responsibility clearly, and creating a well-documented procedure to sustain collaboration between the development team, QA, and non-technical participants.

A simple way to solve it is to get all specifications before starting the development — as if it is part of the requirement engineering — so the teams can make analysis and get a plan of how to implement and generalize solutions, avoiding getting a partial view of the problem.

Just in case, I must say it loud and clear. BDD is not the place where non-technical participants throw change requests. If BDD starts to be a way to force the development team to commit changes not specified before, this will end up badly. My advice is if this starts to happen, make a red line here and say it clear. Forcing via test to make changes is not the way to proceed. As it has been said, the behavior should be clear before BDD can start if not, there’s no BDD, just UI tests that will not match the real software behavior and responsibility will land in nobody-land until defined.