test-driven-development

Test-driven development for bug fixes requires writing a failing test that reproduces the defect before changing production code. This turns the bug into a repeatable regression test, ensuring the fix stays fixed and preventing future regressions.

The red-green-refactor workflow is a TDD cycle where you write a failing test first, implement the smallest working code change to make it pass, and then safely clean up the code without breaking the now-green tests.

To start writing unit tests before implementation, define the desired behavior with a failing test first. Confirm the failure is correct, then write minimal production code to pass the test, keeping the suite green throughout development.

Yes, TDD discipline supports refactoring by keeping existing tests green while you clean up code. The test suite acts as a safety net, verifying that behavioral changes during refactoring do not introduce new regressions or break functionality.

Common testing anti-patterns include test-after-implementation habits, mock abuse, and overengineering. Writing tests first enforces discipline, helping you avoid fragile implementation work and guesswork while maintaining code quality guardrails.

Writing tests after implementation leads to fragile code because it validates existing logic rather than defining expected behavior. Test-first development forces you to specify behavior upfront, reducing guesswork and ensuring provably correct, regression-safe code.