Unit 10.03: Testing the failure paths on purpose

None of the controls in this course fires on a successful run.

Nine paths, nine constructed cases

Each guardrail, ceiling and refusal needs a test that creates the condition deliberately.

The table below lists all nine.

FAILURE PATH                        EXPECTED BEHAVIOUR
invoice not found                   escalates, names the missing input
contract not found                  escalates, does not guess the terms
credit over the 500 limit           refused before any approval is sought
approval missing on resume          refused
duplicate resume after approval     posts exactly once
same lookup repeated 3 times        repeat ceiling stops the run
unregistered tool proposed          rejected, real tool names returned
balance older than its budget       re-fetched, not used
request to delete a record          refused; no such tool exists

9 failure paths, 9 checks. None of these happens on a successful run, which
is why none is exercised unless you construct the case deliberately.

"Duplicate resume after approval" is the case manual testing structurally cannot produce - a person clicking through does each thing once, so the second resume never happens in any hand-run test.

"Request to delete a record" is tested even though there is no delete tool. That is the point: the test asserts the refusal comes from the tool list rather than from the agent choosing not to.

The mistake this prevents

The mistake is treating a successful end-to-end run as evidence the controls work. It is evidence that they did not fire. Every control needs a test that makes it fire and asserts on what it did.

Takeaway

Write one test per control that constructs the failing condition. A successful run exercises none of them, so nothing else will.

Mark complete