The Testing Agent

Chapter 6 closed on an honest limitation: code review catches what's visible from reading code, but some real bugs only surface once the code actually runs against real data or a genuine edge case. A testing agent exists to catch exactly that gap — writing and running tests, rather than reviewing or implementing.

Designing a Testing Agent's Definition

"Use this agent to write tests for new or existing code, or to run the existing test suite and investigate a failure. Not for implementing the feature itself — use a coding agent for that." Tools need to cover both writing test files and actually running them: Read, Edit, Write, and Bash (to execute the test suite and read its real output, rather than guessing at whether tests would pass). Model choice should favor a genuinely capable model — writing tests that would actually catch a real regression requires real understanding of the code's intended behavior, not just producing tests that trivially pass.

Writing the System Prompt for a Testing Agent

A testing agent's system prompt should instruct it to:

• Write tests that would genuinely catch a real regression — not tests that simply re-assert whatever the code currently happens to do
• Cover genuine edge cases (empty input, boundary values, error conditions), not just the obvious happy path
• Run the full test suite after any change, not only the newly written tests, since a fix in one place can silently break something unrelated elsewhere
• Report a failure with the actual error output, not a paraphrase of what it thinks the error means

Test-Driven vs. Test-After

A testing agent can work in either order: test-after, writing tests against code that already exists, or test-driven, writing tests first against an intended behavior that hasn't been implemented yet. The brief needs to state which mode is wanted, since test-driven work requires describing the intended behavior explicitly — there's no existing implementation for the agent to read and infer correct behavior from.

Briefing a Testing Agent Well

Following Chapter 3's own principles, a good brief for a testing agent states exactly what to test, what correct behavior looks like — especially for edge cases that aren't obvious from a quick read — and whether the task is writing new tests, fixing broken ones, or diagnosing a specific failure.

A Worked Example

"Write tests for the discount calculation function in src/orders/discount.ts. Cover: the normal multi-item case, an empty cart, a single-item cart, and specifically the off-by-one edge case flagged in the recent code review, where the last item in the cart was being excluded from the discount. Use the same test framework and file conventions already used in this module's existing test files." This tells the agent exactly what to cover, names the specific edge case a prior review already flagged, and points at the existing conventions to follow rather than inventing a new style.

Hands-On Exercises