Test-Driven Development
Test-driven development is a programming practice that alternates a failing automated test, the code needed to pass it, and refactoring. Each short cycle defines one behavior and leaves a repeatable check that protects it.
itSoftware engineering | OpenSkills.info
Intro
Test-Driven Development
Test-driven development, or TDD, organizes programming around small, repeatable feedback cycles. You describe one expected behavior as an automated test before implementing that behavior. You run the test and observe the expected failure. You then change the production code until the full test suite passes. With the suite green, you improve the structure without changing observable behavior.
This sequence is commonly called red, green, refactor. Red establishes that the new test can detect the missing behavior. Green establishes that the implementation satisfies the example without breaking earlier examples. Refactor separates structural improvement from behavior change. The next cycle begins from a working baseline.
The working system
TDD has four interacting parts:
- A test list records behavioral examples still worth implementing.
- A test case supplies inputs, invokes public behavior, and checks an observable result.
- Production code implements the behavior used outside the test suite.
- A test runner executes tests and reports failures with diagnostic information.
The test list guides direction without fixing every detail in advance. Select one item that can expose useful design information. Convert only that item into a runnable test. A large speculative batch of tests commits the design before implementation has supplied feedback.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://agilealliance.org/glossary/tdd/
Supports
- Definition and repeated test-code-refactor rules of test-driven development
- Expected benefits with explicit limits on empirical confirmation
- Individual and team pitfalls, skill progression, and historical milestones from 1976 through 2006
- Quiz answers about the cycle, scope, and refactoring
- https://newsletter.kentbeck.com/p/canon-tdd
Supports
- Canonical test-list, one-test, passing-code, refactoring sequence
- Reasons to keep the test list revisable and avoid a speculative batch of runnable tests
- SUnit in 1994 and the October 1995 OOPSLA demonstration
- Quiz answers about intended red, test sequencing, and new discoveries during green
- https://martinfowler.com/bliki/TestDrivenDevelopment.html
Supports
- Red-green-refactor cycle, test-list sequencing, and interface-first design pressure
- Refactoring as an essential step rather than an optional cleanup phase in practice
- Quiz answers about green, refactoring, and test sequence
- https://martinfowler.com/bliki/SelfTestingCode.html
Supports
- Distinction between TDD and a self-testing regression suite
- Frequent automated execution and test-first defect fixing
- Relationship between self-testing code and continuous integration
- https://martinfowler.com/articles/mocksArentStubs.html
Supports
- Distinction between stubs, mocks, state verification, and behavior verification
- Limits and design consequences of interaction-focused tests
- Quiz answers about observable behavior and real-provider evidence
- https://martinfowler.com/articles/practical-test-pyramid.html
Supports
- Selecting focused tests and using real boundaries where their behavior carries the risk
- Quiz answer about database-specific constraints
- https://agilealliance.org/glossary/refactoring/
Supports
- Refactoring improves internal structure while preserving external behavior
- Quiz answer about structural change under a green suite
- https://gds-way.digital.cabinet-office.gov.uk/standards/test-driven-development.html
Supports
- Canonical red-green-refactor inner loop and fast feedback
- Use of another feedback mechanism when canonical TDD does not fit the uncertainty
- Reference-link rationale and quiz answer about exploratory work
- https://docs.pytest.org/en/stable/explanation/fixtures.html
Supports
- Fixtures provide reliable test context and safe teardown
- Order-dependent failures as evidence to inspect state isolation and cleanup
- https://github.com/sindresorhus/awesome
Supports
- The index identifies awesome-testing as the curated software-testing list
- https://github.com/TheJambo/awesome-testing
Supports
- Service virtualization section identifies WireMock and MockServer as testing ecosystem tools
- https://wiremock.org/docs/
Supports
- HTTP response stubbing, request matching, fault simulation, and verification
- Awesome Links rationale and quiz answer about controlled collaborators
- https://www.mock-server.com/mock_server/getting_started.html
Supports
- Expectation setup, system execution, recorded traffic, and request verification
- Awesome Links rationale
- https://junit.org/junit5/docs/current/user-guide/
Supports
- JUnit assertions, lifecycle hooks, test discovery, and parameterized tests
- Landscape placement, open-source licensing, and free availability
- https://docs.pytest.org/en/stable/contents.html
Supports
- pytest assertions, fixtures, parametrization, selection, and reporting
- Landscape placement, open-source licensing, and free availability
- https://jestjs.io/docs/getting-started
Supports
- Jest matchers, setup and teardown, mock functions, focused execution, and test reporting
- Landscape placement, open-source licensing, and free availability
- https://vitest.dev/guide/
Supports
- Vitest matchers, mocks, focused runs, Vite configuration, and browser mode
- Landscape placement, open-source licensing, and free availability
- https://docs.nunit.org/
Supports
- NUnit assertions, test cases, setup, teardown, and runner integration
- Landscape placement, open-source licensing, and free availability
- https://xunit.net/docs/getting-started/v3/getting-started
Supports
- xUnit.net runner, facts, theories, assertions, and per-test execution
- Landscape placement, open-source licensing, and free availability
- https://rspec.info/features/3-13/rspec-core/
Supports
- RSpec executable examples, expectations, shared context, controlled collaborators, and focused runs
- Landscape placement, open-source licensing, and free availability
- https://docs.phpunit.de/
Supports
- PHPUnit assertions, fixtures, data providers, and test doubles
- Landscape placement, open-source licensing, and free availability
- https://google.github.io/googletest/
Supports
- GoogleTest assertions, fixtures, parameterized tests, and death tests
- Landscape placement, open-source licensing, and free availability
- https://agilealliance.org/glossary/atdd/
Supports
- ATDD definition and adoption through Fit and FitNesse in 2003 to 2004
- Timeline milestone and relationship between TDD and acceptance examples
- https://dannorth.net/blog/introducing-bdd/
Supports
- September 2006 publication introducing BDD and its teaching motivation
- Timeline milestone and BDD relationship to TDD