Test-driven Development
Test-driven development (TDD) repeats three steps. Write a small failing test. Write the least code that passes. Then clean the code without changing how it works.
Another example
A developer starts a new money-rounding rule with one example test that fails. The smallest code makes it pass, then repeated code is cleaned up while all tests stay green. Tests written only after the code are useful, but that is not TDD's test-first cycle.
Main parts
- 01failing example
- 02minimal passing code
- 03safe refactor
Use it when
Use this term when each next design step is led by a failing test and followed by safe cleanup.
Do not use it when
Do not call a project TDD only because it has many tests. The code must follow the test-first loop.
Name used in code
red → green → refactor Before you ship
Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule.
Outcome: Use Test-driven Development to gather repeatable evidence about this behavior or quality risk. User context: A developer starts a new money-rounding rule with one example test that fails. The smallest code makes it pass, then repeated code is cleaned up while all tests stay green. Tests written only after the code are useful, but that is not TDD's test-first cycle. Validation approach: Test-driven Development. Why it fits: Use this term when each next design step is led by a failing test and followed by safe cleanup. Do not use it when: Do not call a project TDD only because it has many tests. The code must follow the test-first loop. Test requirements: Name the system and test environment. Define prepared test data, other inputs, and the result you can observe. Include failure and edge cases, allowed error, isolation, and cleanup. Test operations: Make failures easy to diagnose. Control random or changing inputs. Name an owner. Keep the test fast and simple enough for its release gate. Acceptance criteria: The test fails for the known bug and passes after the fix. It repeats in the target environment, gives useful evidence, and does not expose or change unrelated data. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Release gate, environment, prepared test data, allowed error, time budget, owner, and flaky-test rule.
Check this request
Review the current use of Test-driven Development. Definition: Test-driven development (TDD) repeats three steps. Write a small failing test. Write the least code that passes. Then clean the code without changing how it works. Release checks: Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.