test-driven-development

Test-driven development is a workflow where you write a failing test, implement minimal code to pass it, then refactor. The red-green-refactor cycle enforces this sequence to eliminate untested production code and reduce regressions.

To write unit tests before implementation, start by creating a failing test that defines the desired behavior. Run it to verify failure, then write the minimal production logic needed to make the test pass, ensuring behavior-focused coverage.

Yes, you can use test-driven development across backend, frontend, and full-stack codebases. It enforces a strict test-first workflow for new feature implementation, bug fixes, refactoring, and behavior changes regardless of the stack.

Common testing anti-patterns during refactoring include testing mock behavior instead of actual logic, adding test-only code to production systems, and incomplete mocking. Avoiding these ensures tests remain behavior-focused and reliable.

If TDD tests pass but bugs remain, you may be testing mock behavior rather than real logic or adding test-only code to production. Strict adherence to verifying test failure before implementation and avoiding incomplete mocking prevents this.

Yes, verifying test failure before writing implementation code is mandatory. This confirms the test is valid and actually checks the desired behavior, preventing false positives and ensuring the red-green-refactor cycle works correctly.