BDD vs TDD: An Introduction to BDD and Test Driven Development

The BDD vs TDD question is usually asked as though the two compete. They do not, and the reason is visible in how TDD itself was learned.

Test driven development established itself as a genuine improvement in how software gets built. Write a failing test, make it pass, improve the structure, repeat. Practitioners who have taught it to others describe a fairly consistent arc: a developer starts writing unit tests around their code, gains confidence, then has the insight that writing the test first keeps them from building anything they do not need. At some point they notice the tests also document how the code works. Eventually they realise the practice was never really about testing at all. It was about deciding what the code should do before deciding how.

That last realisation is where behaviour driven development starts, and it is the honest answer to the BDD vs TDD question. Any useful introduction to BDD has to begin there, because otherwise the practice looks like test driven development with extra syntax. BDD is not a competitor to TDD. It is TDD’s own insight taken seriously and moved up a level, to where the people paying for the software can join in.

BDD vs TDD: how test driven development differs

Both practices share a rhythm. State the intended behaviour, watch it fail, implement, watch it pass. On the BDD vs TDD comparison the rhythm is the thing they have in common; the difference is who can read the statement.

A test driven development test is written in a test file, in a programming language, by a programmer. It is precise and it is private. assertEquals(80, account.balance()) is perfectly clear to the person who wrote it and inert to everyone else.

A BDD scenario is written in the language of the business. Given the account balance is £100, when the customer requests £20, then the account balance is £80. A product manager can read it, disagree with it, and correct it. That is the entire point, and it is why getting the words right matters more in BDD than the choice of framework.

	Test driven development	Behaviour driven development
Written by	a developer	the three amigos, together
Written in	a programming language	the domain’s own language
Level	a unit, a class, a function	a behaviour a stakeholder would name
Read by	developers	everyone with a stake
Fails to tell you	whether the behaviour was wanted	whether the internals are well designed

Why the word “test” got in the way

Dan North’s account of coining the term is a teaching story, not a tooling one. Coaching developers into TDD, he kept hitting the same objections, and they clustered around the word. Programmers said writing tests was the tester’s job. Testers asked why programmers were writing tests. Managers asked why the schedule now contained a testing phase that had not been there before.

None of those objections are about the practice. They are all about the noun. Renaming the artefact from a test to an example of desired behaviour dissolved most of them, because nobody argues that a team should avoid agreeing on what it is building.

The renaming is not cosmetic. Once the artefact is a specification rather than a test, it becomes reasonable to write it before the conversation is finished, to show it to a customer, and to treat a disagreement about it as valuable rather than as a defect report.

Where an introduction to BDD usually goes wrong

The most common failure is adopting the syntax without the conversation. A team installs Cucumber, writes Gherkin after the code is finished, and ends up maintaining a slow test suite in an awkward second language for no gain. The scenarios pass. Nobody outside the team has ever read one.

The second failure is pushing BDD down to the unit level. Given/When/Then describing the internals of a sorting routine is worse than a plain unit test: longer, slower, and readable by nobody who was not going to read the code anyway.

A shorter introduction to BDD would stop at those two. The third failure is treating the scenario count as progress. Two hundred scenarios covering behaviour nobody disputed is a maintenance liability. Six scenarios covering the rules the team argued about for an hour is the whole return on the practice.

What behaviour driven testing does and does not cover

Behaviour driven testing is the name usually given to this half. Automating the examples gives a suite that fails when the agreement stops holding. That is genuinely valuable, and it is the part most tooling addresses. It is also the smaller half.

Behaviour driven testing is therefore the smaller half. The larger half happens before any file is written, when three people with different concerns discover they had three different pictures of the same feature. That discovery has no artefact and no tool, which is why it is the part most often skipped, and why skipping it is the reliable way to get no value from BDD at all.

For the mechanics of writing the examples, see Gherkin syntax and the Given/When/Then form. For what runs them, the framework list by language covers the current tooling.