BDD Is Back, and AI Is the Reason

Behavior-Driven Development spent a decade as a niche testing discipline. AI coding just promoted it to core infrastructure for how software gets built.

When a model writes most of the code, your job shifts from typing to specifying. Gherkin, the plain-language “Given / When / Then” format behind Cucumber, turns out to be one of the cleanest ways to specify intent for humans and machines at the same time.

The shift

You’re doing product work now. AI handles the mechanical translation from intent to code. The scarce skill is deciding what to build and how it should behave at.

The bottleneck moved too. It’s no longer “can I write this function.” It’s whether everyone (me, the SME, the user, and the model) agreed on what the thing is supposed to do.

The case for Gherkin

One language for everyone. BDD’s founding idea is a ubiquitous language: domain terms shared by business and engineering, so a scenario reads the same way to a product expert and to a compiler. The original academic characterization (Solis and Wang, EUROMICRO 2011) defines BDD as exactly this, a ubiquitous language fused with test-driven development and automated testing.

A contract, not a vibe. A feature file is an executable specification. It states what will happen and, just as importantly, what won’t. That’s a far stronger collaboration artifact than a Slack thread or a ticket description.

It’s a prompt the whole team can read. Hand an AI a feature file, and you’ve told it precisely what success looks like. Run its output back against that file, and you can confirm, in business language, whether the model understood the request or quietly reinterpreted it.

One spec, many runners. A feature file describes behavior, not the level it runs at. The same scenario can be bound to an integration runner that drives the components directly and to an end-to-end runner that exercises the real system, each with its own step definitions. You get fast feedback and real confidence from one agreed description of the behavior instead of two divergent test suites.

It fights “magically passing” tests. A known failure mode of AI-generated tests is assertions tuned to go green rather than to verify anything. Granular Given/When/Then steps anchor each check to an observable behavior, which makes it harder for a test to pass and mean nothing.

More coverage, not more test code. Scenario Outlines let one written behavior exercise many input paths. You expand what’s verified without a matching explosion in test code to maintain.

The benefit practitioners report most consistently is the soft one. A 2018 IEEE survey of 75 BDD practitioners (Binamungu, Embury and Konstantinou) found the draw centered on living documentation and improved communication across stakeholders, scenarios everyone could actually read.

The Achilles heel, and why it’s smaller now

The real cost was always the plumbing. BDD’s historic tax wasn’t writing scenarios; it was wiring each step to test code and keeping it alive. That same 2018 survey found the maintenance burden grows with suite size, duplication becomes a critical problem, and teams can hit a point where parts of the system are “effectively frozen” because the associated scenarios are too painful to change.

AI eats the worst part. Generating step definitions, scaffolding fixtures, and refactoring duplicated steps is precisely the mechanical work LLMs are now good at. The chore that made BDD feel not worth it is the chore being automated.

The honest cons

The evidence base is thinner than the hype. A 2023 systematic mapping of 166 BDD studies (Binamungu and Maro, Journal of Systems and Software) found research clusters around process and tooling, with a real scarcity of hard, industry-based evidence on BDD’s quality and maintenance payoffs. Much of what we “know” is reported benefit, not measured outcome.

AI can make the bloat worse. The documented failure mode is too many overlapping, duplicated scenarios. An eager model will happily generate hundreds. Without discipline, AI accelerates the exact problem the research warns about.

Plain English isn’t automatically clear. Scenarios still drift into ambiguity, redundancy, and lost focus, enough that researchers have built dedicated frameworks just to score scenario quality (Oliveira, Marczak and Moralles, SBES 2019; Binamungu, Embury and Konstantinou, XP 2020). “Readable” does not guarantee “precise.”

Green can still lie. A passing suite proves the scenarios you wrote pass, not that you wrote the right scenarios. BDD narrows the gap between intent and behavior; it doesn’t close it.

Someone still has to own the spec. AI writes the steps, but a human has to decide whether the behavior is correct. That judgment is the job now, and it doesn’t outsource.

The bottom line

BDD’s value proposition, a shared and executable description of behavior, was always strong. What changed is the cost side: AI removes most of the setup-and-maintenance tax that kept teams away. The trade is real, not free. You still need someone who can tell a right scenario from a merely plausible one.

Go deeper

Solis, C. and Wang, X. (2011). A Study of the Characteristics of Behaviour Driven Development. 37th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), pp. 383-387.
Binamungu, L. P., Embury, S. M. and Konstantinou, N. (2018). Maintaining Behaviour Driven Development Specifications: Challenges and Opportunities. IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 175-184.
Oliveira, G., Marczak, S. and Moralles, C. (2019). How to Evaluate BDD Scenarios’ Quality? XXXIII Brazilian Symposium on Software Engineering (SBES), pp. 481-490.
Binamungu, L. P., Embury, S. M. and Konstantinou, N. (2020). Characterising the Quality of Behaviour Driven Development Specifications. Agile Processes in Software Engineering and Extreme Programming (XP), LNBIP 383, pp. 87-102. Open access, and its related work points on to other scenario-quality tools.
Binamungu, L. P. and Maro, S. (2023). Behaviour-driven development: A systematic mapping study. Journal of Systems and Software, 203, 111749.
Wautelet, Y., Nassiri, A. K. and Tsilionis, K. (2023). Investigating Quality Attributes in Behavior-Driven Development Scenarios: An Evaluation Framework and an Experimental Supporting Tool. Practice of Enterprise Modeling (PoEM), LNBIP 497, pp. 125-142.