BDD is like TDD if

I’ve noticed a number of people recently declaring that BDD really is just TDD, such as Robert Martin on Twitter and Ron Jeffries on the XP list. I can understand where this mindset comes from and I’d like to offer my perspective.

Is BDD the same as TDD? Yes. If you’re a programmer, and your entire team is programmers, and all your stakeholders are programmers and you have a single Subject Matter Expert embedded in the team. Which was true of the Chrysler C3 team and other early XP teams. (Take a look at the original C3 team at Chrysler: 10 world-class programmers and an SME.)

BDD is the same thing but for a broader audience: testers, analysts, project and program managers, multiple SMEs covering multiple interrelated domains. It’s interesting that the BDD == TDD crowd are entirely programmers and necessarily see the world through programmers’ eyes: Bob Martin, Ron Jeffries and others saying “BDD is just TDD” is true in the first approximation of “all delivery people are programmers.” As soon as that precondition fails, BDD becomes a different, bigger thing: it becomes the communication across all of those stakeholders to create a single coherent vision and deliver to that. This is the value of living documentation—and shows why you don’t need it until you do: if you’re in that small team of only-programmers you’ll be fine with only-TDD.

It can be argued that the team shouldn’t be anything other than programmers—in the polyglot roles of tester, analyst, etc.—in which case BDD and TDD again collapse into the same space. But in the kind of organisations and teams that gave rise to and shaped BDD we have to solve the more complex communication problems that are (by definition) beyond the scope of TDD.

I’ve been entirely embedded in small teams of programmers for the last couple of years which is why I’ve taken much more of a back seat in the BDD community. The likes of Liz Keogh, Gojko Adzic and Chris Matts have been where the action is with things like real options and specification-by-example, and folks like Aslak Hellesøy and Matt Wynne figuring out how to manage large numbers of long-lived tests at scale. Liz recently wrote about how shifting the language helps to clarify intent.

Kent Beck describes XP as trying to get business people and technical people on the same page, and I have the same goal for BDD. Don’t forget TDD is one small part of XP. BDD has grown to be broader than s/test/should/, because it’s trying to solve a broader problem.