DEV Community

Cover image for Who writes the BDD?
Rodrigo Matola
Rodrigo Matola

Posted on

Who writes the BDD?

Being short and sweet, except for Dan North, who created BDD, I’d say

Nobody writes the BDD

What you write are stories, scenarios, cases, scripts, screenplays or any other name you like but BDD. If we translate the meaning of the abbreviation, Behavior Driven Development, you will see that it makes no sense to say “I will write the behavior-driven development”.

“BDD uses a story as the basic unit of functionality”*.

BDD is a practice. What you can do is describe this practice, not write it down. Making a comparison, it is the same as asking “who writes Scrum”? In this case we have two responsible, Jeff Sutherland and Ken Schwaber, who write the Scrum Guide. The rest practice Scrum just like they practice BDD.

"BDD is as much about the interactions between the various people in the project as it is about the outputs of the development process"*

*Quotes from Dan North’s article “What’s in a Story”.

BDD, Cucumber, Gherkin

It is very common to treat these three terms as if they were the same thing. Despite being closely linked, each term is independent and have “its own life”.

BDD

Image description

It is a software development practice that consists of writing application behavior before testing and development. I put tests first because BDD was a response to TDD (Test Driven Development).

BDD would be another version of TDD, with behavior-based tests written before development. Like TDD, BDD consists of 3 phases:

  1. We start by collaboratively discovering the scope of behavior required by the story.
  2. Once we agree with this behavior, we write the specification in business-readable language.
  3. Finally, we automate the written specification to verify that the system actually behaves as expected.

Cucumber

"Cucumber is a tool that supports BDD.

Cucumber reads executable specifications written in plain text and validates that the software does what those specifications say. The specifications consists of multiple examples, or scenarios.

Each scenario is a list of steps for Cucumber to work through. Cucumber verifies that the software conforms with the specification and generates a report indicating success or failure for each scenario.

In order for Cucumber to understand the scenarios, they must follow some basic syntax rules, called Gherkin". (Copy and paste from What is Cucumber?)

Gherkin

Image description

Gherkin, or baby pickles, are tiny cucumbers… (just kidding!)

"Gherkin is a set of grammar rules that makes plain text structured enough for Cucumber to understand". These rules involve keywords that allow Cucumber to transform written text in natural language into steps for automation. Given, When And Then are some of these keywords.

Although Given, When And Then are officially part of the language used in BDD, Dan North says "This is not mandatory — you can use a different story format and still be doing BDD — but I am presenting it here because it has been proven to work on many projects of all shapes and sizes".

In short:

  • BDD: software development practice
  • Cucumber: tool that converts text into steps for automation
  • Gherkin: language used by Cucumber.

As said at the beginning of this section, the three terms are most often used together, but they are completely independent entities.

Some frameworks do not use Given, When And Then, such as Gauge, Robot Framework and even Cucumber itself! I can talk about this in another article.

You don't do BDD

I’m sure many of you, like me, learned BDD together with Cucumber as a tool for automating tests. I just say that

If you only use Cucumber to automate tests, you don’t do BDD

There’s nothing wrong with this practice, we just can’t call it BDD. As the name implies, BDD is a development technique, not a testing technique. If you use it just for testing, you do BDT (Behaviour Driven Testing).

Until now, only in one team we almost did BDD…

And you, do you do BDD or BDT?

References

Top comments (0)