Test Success, Failure, and Recovery

A capstone that demonstrates only the happy path leaves the most interesting questions unanswered.

Your test dossier should include at least four categories:

1. normal case — expected input produces expected bounded behavior;
2. boundary case — input near a decision or validity boundary;
3. failure case — a dependency or assumption is deliberately broken;
4. recovery/fallback case — the system enters the defined response and records evidence.

Failure tests should be controlled

The goal is not to damage a device or public service. Use deterministic simulation, supplied fixtures, local isolated environments, or synthetic inputs.

For an edge/cloud capstone, a controlled network-loss test can be represented by the simulator's network-off state or by an isolated local test environment. The evidence should show:

• the dependency became unavailable;
• the system detected the condition;
• the expected fallback occurred;
• the event was recorded;
• normal behavior returned after restoration, if recovery is part of the design.

Retest after a safeguard

If a failure reveals a problem and you change the design, rerun both:

• the failure that motivated the change;
• a normal case that should still work.

This is a regression check. A safeguard that fixes one problem while breaking the required function is not a complete success.

Before moving on

Create a four-row test matrix for your capstone: normal, boundary, failure, recovery. For each row, name the evidence you expect to collect.