Case study
Test strategy: Worlds 2026 Live
Worlds 2026 Live is a real-time tracker for the League of Legends World Championship: a Next.js PWA that syncs the official lolesports feed into Supabase every 5 minutes and serves a match center, bracket, standings, pick'em and push notifications. This page is how I keep it honest: every claim below comes from the repo's tests/ directory and CI workflow, not from memory.
41
Vitest cases
8
Risk areas
4
CI gates: lint, types, tests, build
What is covered, by risk
The map shows where the 41 tests sit: cell intensity and the number show how many tests are mapped to each risk area. Select a cell to open its coverage.
The app re-syncs the official lolesports feed every 5 minutes. The expensive failures are silent: stale data shown as live, or a retry storm duplicating writes.
- Re-syncing identical upstream data changes nothing (idempotent)
- When upstream fails, cached data is kept and the error is recorded
- Retries back off and give up loudly after the last attempt
- A manual override is never overwritten by older upstream data, and never overwrites newer
- A failing stats feed does not fail the whole sync
- Missing database tables fall back to memory, then retry later
How it runs
Every push and pull request runs the same gate in GitHub Actions: ESLint, a strict TypeScript check, all 41 vitest cases, then a production build. A failing gate blocks the merge. The badge at the top of this page reads the latest run live from the GitHub Actions API.
Known gaps, said out loud
- No browser-level end-to-end tests in this repo. The suite is unit and integration level. UI flows are verified manually before each deploy. (My ShelfSeeker project is where I keep the full Playwright E2E practice.)
- The live feed's real schema drift is only caught at sync time; the sync tests pin behaviour with recorded fixtures, not against the live API.