Behavior Driven Development (BDD) has been around as a practice for some time now, ever since it was introduced by Dan North back in 2006 (at which point it had already been evolving for a couple of years). Tools to support the BDD process, such as Cucumber, SpecFlow and JBehave, have existed for just as long. These tools support one of the two main components of the BDD approach: turning behavior into automated tests (the other part of BDD concerns the creation of these specifications in a ubiquitous language).

Despite having been around for so long, there's still a lot of debate going on as to how and when (not) to use BDD as a practice and BDD-supporting tools to support this practice in your software development process. Should you adopt BDD? Should you use BDD-supporting tools? Can they only add value when used together? There are definitely arguments for every side of the discussion. In this article, I would like to zoom in a little deeper on each of the available options.

Create specifications that describe desired behavior, verify them using tools

It should not be a surprise that you’re likely getting the most value out of practicing BDD when you implement both of the components that the practice consists of. But what does practicing full blown BDD look like?

Create Specifications

Whenever you are about to add a new piece of functionality to your application, or change an existing one, for that matter, the different roles involved in creating this feature have a facilitated discussion (a so-called ‘three amigos’ session) that is intended to flesh out the desired behavior of the application with regards to this new feature, as well as to clear up any misperceptions about what it is the new feature should do exactly.

I’d like to summarize the outcomes of a three amigos session like this. After such a session:

• The product owner or business analyst has an understanding about what they will get in terms of added value from the feature,
• The developer has an understanding of what they will need to build,
• The tester has an understanding what they will need to test for, and
• This understanding is a shared understanding between all three parties

Automated Acceptance Tests

These specifications that describe the intended behavior, typically written in the Gherkin "Given… When… Then…" syntax, are then used to drive the automated acceptance tests for these features. There’s a wide range of tools available that help you perform this step of turning readable specifications into executable code.

The main benefit of adopting both components of BDD is that they play to each others strengths: creating specifications that express intended behavior of a feature and that are understood and agreed upon by the whole team, results in a set of acceptance tests that are a great starting point for both testing and test automation, and automated verification of the expected behavior after the feature has been created supports creating confidence that the software that has been built actually supports the desired behavior and associated business value.

Discussion without Test Automation

In some specific contexts, facilitating discussions to create a shared understanding of the behavior that a feature is expected to exert can be really beneficial to the software development process, even when these specifications aren’t verified by use of tools afterwards. Sometimes, the benefits that are generated by having a collection of automated tests just do not warrant the efforts needed to create them in the first place!

In these situations, you can still benefit from the reduced risk of misunderstanding that’s the root cause of many a defect in software. As Dan North, the originator of BDD, put it in one of his talks: BDD is not about testing! So, even when you follow a different approach with regards to your test automation, or maybe you don’t have any test automation in place at all, there’s still a lot of potential value in having ‘three amigos’-like discussions to create a shared understanding of what the software you’re going to build is supposed to do.

Use Tools to Execute Specifications Outside of BDD

Increasingly often, I see teams and organizations adding a tool to create executable specifications (e.g., Cucumber, SpecFlow or HipTest) to their test automation stack, even when these specifications have not been created through discussion as the BDD process recommends. The rationale behind this decision is often that ‘it makes our automated tests readable for everybody.'

Now, finding a way to make the scope and the intent of your automated tests readable and understandable to everybody (and by ‘everybody’, what’s usually meant is ‘people that can’t or rather don’t want to read code’) is definitely a good idea. But before you add a tool to create and run executable specifications to your solution, please consider that:

• These executable specifications form another layer of abstraction in your test automation code, and as any other layer, it needs to be maintained, which takes time and effort
• Creating executable specifications with the sole intent to drive and document automated tests can easily lead to specifications that aren’t all that readable anymore, vastly reducing or even nullifying the added value that this added abstraction layer intended to produce in the first place
• It is possible to create easily readable tests without adding an executable specification layer, by using proper abstraction techniques in your code combined with useful naming of classes, variables and methods.

That doesn’t mean you should never make use of executable specifications when these are not created through a facilitated discussion as prescribed by BDD, but please be careful that doing so comes at a cost, and this cost should be warranted. What’s the intended audience for the executable specifications? Do they really read them?

Behavior Driven Development isn't Always the Answer — and That's Okay!

Of course, you might also decide that BDD is not for you. There are contexts in which BDD might not be the best option, or, as Thomas Sundberg expressed it in a Cucumber.io blog article in 2016 (please note that this is not an exact quote), “sometimes the business does not have a reason to have an opinion about the behavior of the software.” In those cases, adopting the BDD process, or using tools that support BDD, might not be the most effective option.

In the end, it all comes down to the context in which software development takes place. In some cases, adopting full-blown BDD might be the best solution. In other cases, you might decide to only use facilitated discussions to create a shared understanding of the expected behavior of the software that you’re developing, or you might decide to use a tool that supports executable specifications without incorporating these discussions at all. The key word here is ‘context.’ What works great in one situation might be a terrible fit somewhere else. There’s more than one way to create good software!

Bas Dijkstra is a test automation trainer and consultant who’s always looking for more intelligent ways to use tools to improve test processes and software quality. He’s been in the field for over 13 years, designing and developing solutions that enhance and improve test teams and test processes. You can read more about him by reading his blog or following him on Twitter.