acceptance-tests-observable-outcomeslisted

# Acceptance Tests Assert What the User Sees Unit and integration tests answer "did we build it right" — they assert code paths ran. Acceptance tests answer "did we build the right thing" — they assert what a user or caller actually observes on the real system. Only the second catches a feature that was fully specified, fully coded, and never actually wired to anything a user can reach. ## When to use Whenever a spec's success criteria describe an observable outcome — a value on screen, a header in a response, a file left on disk, a specific error message — and before claiming that feature, or any piece of automation, is done. Reach for it any time you're tempted to answer "does it work" by re-reading the code that's supposed to make it work, instead of watching it work. Red-flag thoughts that mean STOP and apply this skill: - "The unit tests are green, so the feature works." (Green units prove the pieces; they don't prove the pieces are wired together for the user.) - "I traced the code path by eye, it clearly returns the right value." (A trace is not an execution.) - "The mock returns what production would return." (Then you've tested the mock, not the outcome.) - "It passed once, that's enough — this isn't safety-critical." (One green run on a non-deterministic path is luck, not proof.) - "Cleanup only matters if the test passes." (A failing run that skips teardown leaves debris the next run inherits.) ## The rule 1. **Derive each acceptance test from an observable