Short definition

Test Driven Development — a development discipline in which the test describing the expected behaviour is written before the code that implements it.

Full definition

In the established technical sense, TDD refers to a short, repeated cycle: write a failing test, write the minimum code that makes it pass, refactor the code without breaking the test. It is as much a code design practice as a testing practice.

In the articles on this blog, the term is used from a narrower angle: the test written before the code is valued as a specification artefact. It carries the what — the expected behaviour, what must stay true — while the code carries the how. As such, it matters to product as much as to development: it records an agreement on a behaviour in a form the machine evaluates, and which therefore cannot silently drift from the implementation.

Usage in the field

Discussions about reducing the number of defects shipped, defining a quality policy, deciding how much to spend on tests, formalising a feature's acceptance criteria.

Layer added by "Ontology-Driven Design: what if the ontology became the safety net for AI-generated code?" (2026-10-29). The term also serves as a model for analogy: TDD's logic of doing things first is carried over to the domain model, by holding a request up against the ontology before coding, without the deterministic guarantee of a test.

Synonyms and variants

Test Driven Development · test-driven development · test-first.

Not to be confused with

• Automated tests — tests run by a machine, with no indication of when they were written; written after the code, they record what it does.
• BDD (Behaviour Driven Development) — expressing expected behaviours in a language non-developers can read, geared towards conversation with the business.
• Regression tests — a set of tests rerun to check that an existing behaviour has not been broken, regardless of whether they were written before the code.
• QA — the function that defines and verifies quality criteria; TDD is a practice carried out by the developers themselves.

Examples

"The test describes the what. The code implements the how."

An expected behaviour pinned down by a test before implementation stays verifiable after several rounds of refactoring, whereas the prose that described it has long stopped being reread.

Ambiguities / debates

The acronym is often used for any automated testing practice, which erases the one thing that defines it: the test comes before the code.

Its value is still debated — a design practice for some, a writing overhead for others — and the debate rarely concerns the same thing, depending on whether people mean the full cycle or test-first alone.