Day 4: Audit your E2E coverage

If your E2E tests were written incrementally as the app grew, they almost certainly cover pages rather than journeys. That distinction sounds academic until you discover that your most-broken user flow has no test at all — and your coverage report showed 80%.

What we tried

We started by asking Claude Code to do something we'd been postponing: walk the repo and tell us what user journeys existed.

The prompt we used:

Read every route and page component in /src/app and /src/pages.
For each one, describe the primary user journey it participates in —
not the component name, but what the user is trying to accomplish.
Then read every file in /e2e and list which journeys have test coverage
and which don't. Output a gap list, not a coverage percentage.

Claude Code walked the file tree, read the route components, matched them against the test files, and produced something we hadn't had before: a journey map with coverage status.

The output looked roughly like this:

User journeys found:
- Sign up (new user) ............. COVERED
- Sign in (returning user) ....... COVERED
- Browse catalog ................. COVERED
- Add to cart .................... COVERED
- Complete checkout .............. COVERED (steps 1–3 only)
- Abandon cart, return later ..... NO TEST
- Apply discount code ............ NO TEST
- Account settings update ......... COVERED
- Password reset ................. NO TEST
- Order confirmation email link .. NO TEST

Four uncovered journeys. The checkout one only covered the first three steps — there was no test that confirmed the confirmation screen rendered or that the order was persisted.

What happened

The gap list was uncomfortable to read. We had a test called checkout.spec.ts that gave us confidence — but it stopped at "place order" without verifying what came after. That's the most common failure mode: tests that walk into a flow but don't confirm the exit.

Two surprises came out of the audit:

The abandon-and-return flow was the #2 support ticket source. We didn't know this until we correlated the gap list with the support queue. The test coverage gap and the production pain were in the same place.

Password reset was tested in unit tests but not E2E. The unit test verified the token generation. It didn't test that the email link landed the user on the correct page with the correct form state. That's a different test.

Once we had the gap list, prioritization was simple: we sorted by user impact and started from the top.

What we learned

• Coverage by journey map, not by file count. A file-level coverage percentage will always look better than reality because it can't see the flows that span multiple files.
• Ask Claude Code to read your routes and pages and map them to existing test files. This takes maybe two minutes of prompting and gives you the gap list you need to have a real conversation about testing priorities.
• A gap list is more valuable than a coverage percentage. "We have 4 uncovered journeys, one of which is the #2 support ticket source" is a sentence your team can act on. "82% E2E coverage" is not.
• Tests that stop at the action without confirming the outcome are half-tests. A checkout test that doesn't verify the confirmation screen is a test for "the button didn't error," not "checkout works."
• Keep a coverage matrix in the repo — even a simple markdown table. When it lives next to the code, someone looks at it during PR review. When it's in a wiki or a dashboard, no one does.

Next

• Day 5 — Permissions and your first settings.json.