There’s a lot to like about behavior-driven development (BDD). When applied in the right way, BDD can narrow communication gaps, inject real-world examples into strategic discussions, and foster a better understanding of the customer. It can help eliminate the many wasteful activities that often hinder software development, such as rework caused by misunderstood or vague requirements, technical debt caused by reluctance to refactor code, and slow feedback cycles caused by the proliferation of silos.

Applied correctly, there is a place for BDD in the modern world of software development. Test automation, however, is not that place. 

RELATED CONTENT: Overcoming the challenges of adoption BDD in the enterprise

As promising as BDD is as a general software development methodology, it’s almost always a hindrance when applied to test automation. This isn’t speculation or guesswork, either. It’s something that plays out over and over again in my work as a solutions architect. Among the dozens of organizations and hundreds of engineers I interact with, the ones that struggle the most are those attempting to apply BDD to their test automation efforts. 

Haste makes waste 
There are many reasons this repeatedly proves to be the case, but let’s focus on the most glaring: most organizations aren’t truly following the core principles behind BDD. Instead, they hear the buzzword and move quickly to implement it before truly understanding the right way to do so. 

If that sounds familiar, well, that’s because it’s an all-too-common refrain in the tech industry. A groundswell develops behind a given method, and we move hastily to implement it without understanding the foundational principles or thoroughly reading through the available documentation. As a result, we turn a well-intentioned idea into a Frankenstein of our own making. 

That’s how we end up with something like waterfall agile, where we grab a few pieces of the Agile Manifesto and combine it with waterfall. Or Selenium Webdriver for API automation, where we take a tool designed for a specific purpose and use it to solve all of our automation problems. Or, in this case, how we end up with BDD test automation, an approach that provides only technical limitations and disadvantages. 

A poor fit 
The problem with applying BDD to test automation isn’t just that we’re doing it wrong, however. It’s that when we apply BDD to test automation, we inherently open ourselves up to a litany of problems that undermine what we’re trying to accomplish in the first place. Let’s take a closer look at four of the most significant of those problems. 

  1. The wrong person takes control

Behavior-driven development centers on the notion that the behavior of a system should drive the design of that system. As such, the system and its requirements should be defined by those who best understand its behavior. BDD ideally involves a collection of players within the development process collaboratively developing a common language around system requirements. Those groups best suited to do this for a test automation workflow are usually some combination of developers, manual testers, and business analysts. In practice, however, that’s usually not what we do. We tend to ignore the potential communication benefits of BDD and drop the responsibility of creating the BDD spec files that guide the process on a single person, usually the automation engineer.

Automation engineers certainly play a vital role in the development process. But are they most qualified to write the requirements of a system in Gherkin syntax? And are they most qualified to implement that automation in the most efficient manner possible? Usually not. As a result, they often simply convert manual tests into Gherkin scenarios, without having a business conversation, and often use a UI automation tool to solve every problem, rather than leveraging unit or integration tests.

  1. BDD tools create extra dependencies

Another inherent problem in applying BDD to test automation is that it creates an extra layer of dependencies. As any experienced developer will tell you, limiting the number of dependencies in software is at the core of most programming principles. Every dependency is a chance for something to go wrong. When tests fail, it’s usually because a test suite became too complex and contained too many dependencies. If you’re an automated tester, limiting dependencies has to be your priority.

  1. BDD tools struggle with parallelization 

Parallelization is mandatory if you want to achieve automation at scale and test across the vast number of browser/OS/device combinations that the modern landscape requires. Unfortunately, the most popular BDD automation tools are sub-optimal at driving parallelization. They parallelize at the feature file level, which means that if you want to run 50 tests in parallel, you need to have 50 feature files (and that’s a lot!). There are workarounds, but they’ll cost you time and money, and your automation efforts will likely be no better off anyway.

  1. Tests become less readable, not more 

Perhaps the most common argument in favor of applying BDD to test automation is that it makes tests more readable. And then, almost without fail, the exact opposite happens. The reality is that most of us don’t follow the correct Gherkin syntax as the creators of BDD intended (ignoring rules such as writing all steps in a third-person point of view, and writing steps as a subject-predicate action phrase). We’re left with tests in which it’s often impossible to discern what it is we’re actually trying to validate from an end-user perspective. That’s counter-intuitive to good test automation (and to good BDD, for that matter). 

It’s ok to say no 
The desire to apply an exciting new methodology like BDD is understandable. But test automation is challenging enough, and over and over, BDD has proven to make it even more challenging, while adding little in the way of benefit. Sometimes discretion is the better part of valor, and it’s ok to say no. Such is the case with BDD and test automation.