tdd

Test-driven development for an API endpoint involves writing a failing behavior-level test for the happy path, implementing minimal code to pass it, and then refactoring safely. You incrementally add error cases as separate red-green-refactor cycles to ensure full test coverage.

The red-green-refactor workflow is a test-driven development cycle where you write one failing test, make it pass with minimal implementation code, and then clean up the design while keeping the test suite green. This proves each behavior before considering the code done.

You should not write unit tests for private implementation details. Behavior-focused testing validates public interfaces and user-visible contracts instead, ensuring your tests remain durable through safe refactoring and do not break during internal structural changes.

Test-driven development is highly effective for fixing software bugs. You write a behavior-level test that reproduces the bug and fails under current code, then apply the minimal fix to make it pass, preventing future regressions and clarifying the exact requirements.

Test-driven development is less suited for tasks lacking clear public contracts or observable behavior. If a software task involves exploratory implementation without defined module boundaries or pure functions, writing behavior-level tests upfront becomes difficult and unproductive.

The tdd skill guides vertical slice development by building features incrementally, one tracer bullet at a time, rather than writing all tests upfront. It drives feature implementation through test-first cycles around observable behavior for pure functions and module boundaries.