TDD in Laravel

The red → green loop, tuned for Pest/PHPUnit in a Laravel codebase. Consult before and during the loop, not after.

Read CONTEXT.md if it exists so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.

Before writing or reviewing tests, read references/testing-best-practices.md and apply its value gate and rejection rules throughout the loop.

Rules of the loop

• Red before green. Write the failing test first, watch it fail for the right reason (a missing route 404s, not a typo'd import), then write only enough code to pass. No speculative features.
• One slice at a time. One seam, one test, one minimal implementation per cycle. Each next test responds to what the last cycle taught you — never all tests up front, then all implementation (bulk tests verify imagined behavior and go insensitive to real changes).
• Refactoring is not part of the loop. It belongs to the review step (code-review).

What a good test is

Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — user cannot view another users invoice says exactly what rule exists — and survives refactors because it doesn't care about internal structure.