Test-driven Development

Test-driven Development, or TDD, is a practice where you write a failing test that describes the behavior you want before you write the code that satisfies it, then work in a tight red-green-refactor loop until the test passes and the code is clean. Kent Beck popularized it as part of Extreme Programming in the late 1990s, and it inverts the usual order of work so that the test becomes the specification. The point is not testing for its own sake — it is letting the test drive the design.

• Red-green-refactor - Write a failing test (red), write the minimum code to pass it (green), then clean up (refactor) without changing behavior.
• Executable specification - Each test states an expectation in code, so the suite becomes a living, runnable definition of what the software is supposed to do.
• Tight feedback loop - Small increments keep you seconds away from knowing whether you broke something, which is where the confidence comes from.
• Design pressure - Writing the test first forces you to think about interfaces and seams before implementation, usually producing simpler, more testable code.

In API work TDD shows up as contract-first and Test First discipline: you write the tests that assert an endpoint’s response shape, status codes, and error behavior before the endpoint exists, then build until they pass. Those same assertions graduate into Test Suites and CI pipelines that guard every future change, and increasingly they become the machine-checkable contract that governance tooling and agents rely on to trust an API. When I score a provider, the presence of real, runnable tests woven into the lifecycle is one of the clearest signals that a team treats its API as a product rather than an afterthought.