test-driven-development

To start test-driven development, write a single minimal failing test that asserts the next behavior you want, implement only enough production code to make it pass, then refactor while keeping the test suite green.

The red-green-refactor cycle enforces writing a failing test (red), implementing minimal code to pass it (green), and refactoring without changing behavior, preventing regressions by verifying every code change meets requirements.

To fix a bug where empty input is accepted using TDD, write a failing unit test asserting the expected validation error, implement the smallest code change to make it pass, then refactor and run the full suite.

You can use mocking in test-driven development when unavoidable, but you must avoid mock-only assertions by verifying the actual behavior and outputs of the system rather than simply asserting that mocks were called.

You should never write tests after production code in TDD because the Iron Law requires a failing test first; if you write code before the failing test, you must delete the code and restart the cycle.

Common red flags in test-first development include rationalizing tests after writing code, writing vague or coupled tests, and relying on mock-based assertions instead of verifying real behavior and pristine outputs.