CLAUDE CODE AGENTS: FUNDAMENTALS - Chapter 7, Exercise 1
Test-Driven vs. Test-After: Why the Brief Needs to Differ
====================================================================================

QUESTION:
Explain the difference between test-driven and test-after work, and why a
brief for test-driven work needs to include something a test-after brief
doesn't.

SOLUTION / EXPLANATION:

Test-after work means writing tests against code that already exists - the
testing agent can read the existing implementation directly to understand
what it currently does, and write tests confirming (or challenging) that
actual behavior. Test-driven work is the reverse order: tests are written
first, before any implementation exists at all, meant to define what the
correct behavior SHOULD be once the code is eventually written.

This difference in order creates a real difference in what the brief must
contain. In test-after work, the testing agent has a fallback source of
truth available even if the brief is a little thin - it can read the actual
code and infer intended behavior from what's already there. In test-driven
work, that fallback doesn't exist: there is no implementation yet to read,
so the testing agent has absolutely nothing to infer correct behavior from
except whatever the brief itself explicitly describes. If the brief doesn't
state what "correct" looks like - the expected output for given inputs,
how edge cases should behave - the agent has no way to write meaningful
tests at all, since it can't observe intended behavior anywhere else.

So a test-driven brief needs to include an explicit description of the
intended behavior itself - essentially a specification - which a test-after
brief can often get away with omitting or stating more loosely, since the
existing code itself serves as a fallback description of what's expected.

--------------------------------------------------------------------------
WHY THIS WORKS AS AN ANSWER:
It explains the order difference (existing code vs. no code yet) and then
traces specifically why that order difference forces test-driven briefs to
supply an explicit behavior specification that test-after briefs can often
rely on existing code to substitute for instead.