Glossary › Code

test-driven development (TDD)

A programming method where the test is written first, followed only by the code that must pass it.

In plain terms

Imagine a teacher who first writes the answer key for the exam and only then starts teaching the material. This way, from the beginning, they know exactly what the student needs to know at the end. Test-driven development does the same with software: first, they record what it means to "work well," and only then do they write the program itself.

A test here is a small program that tries out the code being prepared and says whether it does what was expected. For example, if an online store's cart must give a 10 percent discount, the test enters an amount and checks whether the final result matches.

This is the reverse of the usual sequence: most people write the program first and test it afterwards. In TDD, the test is the commission and the code is the delivery. In the AI era this has become important again because a coding agent can see clearly from the test when it is done, and does not have to decide for itself whether its work is good enough.

How it works

1. The developer (or the coding agent) writes a short test for a single small expectation, for example: 'with an empty cart, the total is zero.'
2. It runs the test, which fails at this stage since the code does not yet exist. This is the 'red' state, proving the test actually measures something.
3. It writes the simplest possible code that passes the test. This is the 'green' state.
4. It tidies up the code and makes it clearer while all the tests stay green. This is called refactoring.
5. The next small expectation arrives, and the cycle restarts. In the end, the multitude of tests provides a safety net: if a later modification breaks something, it is immediately revealed.

An everyday example

Who is affected

A common misconception

Limits and risks

• The test itself can be flawed: if a wrong expectation is recorded, the program will perform the wrong thing well.
• A coding agent may be prone to rewriting the test or "gaming" the code to match the test, rather than solving the task, so it is advisable to prohibit it from modifying tests and to review the final result.
• It takes more time at the start, and the return on investment only becomes visible later, during maintenance.
• It is difficult to apply where the outcome cannot be described by a clear expectation, such as with visuals, user experience, or the variable responses of an AI model.

Similar, but not the same

• software testing – Testing usually checks the finished program afterwards, but in TDD the test is created first, and it dictates what code is written.
• vibe coding – In vibe coding, you accept what the AI writes based on intuition without checking the code, whereas TDD ties every step to pre-defined checks.
• behavior-driven development (BDD) – BDD grew out of TDD, but it describes expectations in everyday language from the user's perspective so the business side can understand it.

Related concepts

A brief history

American software developer Kent Beck popularized the method as part of extreme programming, then described it in detail in his 2002 book Test-Driven Development: By Example. He himself said that he did not invent the old practice but "rediscovered" it.

Where things stand

A method long known in the software industry, though not consistently applied everywhere. By the end of 2026, it has gained new momentum due to coding agents, because testing is one of the most reliable ways to automatically verify an agent's work.

Status: 2026 November

Also known as

TDD · test-driven development · test-driven development · test-driven programming · test-driven development · test driven development · test-first development · red-green-refactor

Sources

• Wikipedia: Test-driven development
• Martin Fowler: Test Driven Development

This entry was machine-edited and has undergone machine expert review; the “In the news” section updates automatically from Agent Age stories.