← ClaudeAtlas

e2e-testinglisted

How to validate a change end-to-end (repro-first), not just with unit tests. Use when making or verifying code changes, fixing bugs, or when asked to prove a change works. Only load when actually changing/validating code.
vinaygiri/fleetmind · ★ 2 · Testing & QA · score 68
Install: claude install-skill vinaygiri/fleetmind
# End-to-end testing (repro-first) Unit tests are the fast guard; they are not proof the product behaves. Prove behavior by driving the real flow the way a user would. ## For bug fixes 1. **Reproduce first.** Recreate the bug end-to-end, as close to the real user path as possible, before writing any fix. Capture the failing observation. 2. **Fix.** Make the minimal, faithful change. 3. **Re-drive the same path.** Confirm the repro is gone by exercising the flow again, not only by a new unit test. 4. **Add a regression test** with real assertions that reproduces the original bug. ## For features / changes 1. Identify the real entry point (UI action, API call, CLI command, queue message). 2. Drive it against a realistic input in a running environment (local stack / dev app), not a mock, for anything data-correctness, architectural, or pipeline-touching. 3. **Record evidence** of it working: a screenshot, a short video, or a log excerpt. This is what the review gate escalates to the human — make it concrete. ## What counts as evidence - UI change → screenshot or screen recording of the new behavior. - API/data change → request + response (or before/after data) captured in a log. - Background/pipeline change → the payload injected and the downstream result observed. ## Notes - Prefer the project's existing local stack / run command; check the repo memory file for how to launch it and inject a payload. - If a change is trivial and fully covered by a unit test, a