tdd

Test-driven development aligns software requirements with code by enforcing a test-first workflow. You write a failing test from the spec, implement minimal production code to pass it, and refactor while keeping tests green, ensuring every change is traceable to a requirement.

The red-green-refactor cycle in unit testing is a discipline where you first write a failing test, then implement the minimal code required to turn that test green, and finally refactor the code while keeping the tests green to ensure software quality.

To start writing tests before code for a new feature, draft a failing unit test that defines the expected behavior based on your spec. Then, implement only the minimal production code required to pass that test, followed by any necessary refactoring.

Yes, spec-driven testing applies to bugfix work across an existing codebase. It requires writing a failing test that reproduces the bug based on the spec, then implementing the minimal code to pass the test, verifying the fix and preventing future regressions.

You write a failing test before production code to validate that the test actually checks the expected behavior and links the spec to the implementation. This test-first discipline ensures changes are verified from the start and reduces hard-to-track regressions.

You should reconsider test-first development when your specs are undefined or rapidly drifting, as this discipline relies on linking clear requirements to tests. Without stable scenarios, writing failing tests first may cause misaligned expectations and wasted cycles.