test-driven-development

Test-driven development (TDD) is a test-first workflow where you write a failing automated test, implement minimal code to pass it, then refactor while keeping tests green. This cycle is called red-green-refactor and ensures tests actually verify behavior.

To write a failing unit test for TDD, create an automated test that demonstrates the desired behavior, run it to confirm it fails for the expected reason, then implement the minimal production code required to make that specific test pass.

Yes, test-first development applies to bug fixes, refactors, and behavior changes. You write a failing automated test that reproduces the bug or specifies the new behavior, then implement minimal code to pass it and verify no regressions across the suite.

The best way to verify a failing test in TDD is to run it immediately after writing it and check the failure output. Confirm the test fails specifically due to the missing implementation, not due to syntax errors or unrelated setup issues.

Requiring failing automated tests before production code eliminates fragile development by ensuring the test actually validates the desired behavior. This test-first approach prevents false positives and confirms the test fails without the implementation.

Maintain test hygiene and prevent regressions by keeping tests green throughout refactoring, running the entire test suite to verify passes explicitly, and ensuring no production code is written without a prior failing test specifying the behavior.