tdd

Behavior-focused testing targets public seams so your tests survive refactors and read like specifications. You write assertions against public interfaces one slice at a time, avoiding implementation-coupled or tautological assertions that break during internal changes.

The red-green-refactor cycle enforces a strict test-first workflow where you write a failing test, implement the smallest code change to make it pass, and then refactor. This ensures your tests describe real behavior before the implementation exists.

Mock system boundaries when you need to isolate external dependencies and keep tests meaningful. You should mock at the edges to avoid tautological tests while ensuring your behavior-focused integration tests validate real interactions without coupling to internal implementation.

To start writing a failing test, select a public seam, define the expected behavior for one slice, and write an assertion that fails. Then implement the smallest code change to make that failing test pass, following the strict red-before-green workflow.

Yes, test-first development applies to fixing regressions and adding flows like checkout. You guide the process by writing a failing test that describes the expected behavior, then implementing the minimal change to make it pass.

Tests break during refactoring when they are coupled to implementation details rather than public behavior. Writing behavior-focused tests at public seams and avoiding tautological assertions ensures your tests survive internal refactors.