This site uses one functional cookie to keep feature rollouts consistent for you. Nothing is set until you choose. See the privacy notice.
Dev notes
2729+ tests (2670 unit + 59 e2e) — Vitest, Testing Library, MSW, and Playwright. Pure functions first, then hooks with fetch mocking, with a specific technique for proving that optimistic updates actually fire before the server responds.
One principle that should be followed and be non-negotiable is Test-Driven Development (TDD). This codebase, before the change, had zero test files. The goal was to close that gap by targeting the parts of the codebase that are actually worth testing: the rate limiter, the calendar layout algorithm, the vitals formatting, and the hooks with their optimistic update behavior.
renderHook and waitFor — both are needed for anything that touches React QueryonUnhandledRequest: "error" so any fetch without a registered handler fails the test immediately instead of silently passingnext/server and Auth0 and require a Next.js runtimeThe first attempt at testing optimistic updates used a fetchCount variable to make the GET handler return different data on first vs subsequent calls. It worked, but it was testing the wrong thing — it verified the end state after a completed mutation cycle, not whether the cache updated before the server responded.
The fix is delay() from MSW. Add a 300ms pause to the POST/PUT/DELETE handler, then fire the mutation without awaiting it. The mutation is still in-flight when the assertion runs, so the test is checking the actual optimistic state — what the user sees before the server has responded.
The calendar's layoutDayEvents function takes a list of same-day timed events and assigns each one a column index and a total column count, so they can be absolutely positioned side by side in the time grid. The tests cover: a single event gets column 0 of 1, two non-overlapping events share column 0, two overlapping events get separate columns, three simultaneous events get three columns each reporting totalColumns: 3, and pixel positions derived from the row height constant. This is the kind of logic that looks simple but has enough edge cases to be worth specifying in tests.
Tests only matter if they run automatically. A GitHub Actions workflow runs typecheck and the full unit suite on every push to main and develop, and on every PR targeting main. A second job runs after the first passes: it installs Chromium, boots the dev server, and runs the public Playwright suite — which includes axe-core accessibility scans on the landing page, TCG browser, and card detail page. A WCAG 2.1 AA violation blocks the merge just like a failing unit test. Vercel deploys are gated on both checks passing.
Every test uses factory functions instead of shared fixtures. makeEvent(), makeCountdown(), and makePage() accept optional overrides and return fresh objects with randomized IDs. No let declarations, no beforeEach mutations. Each test constructs exactly what it needs and nothing is shared between tests.
Update — August 16, 2026
The section above ends on the line that tests only matter if they run automatically, and I believed it enough to gate this app’s deploys on it. The design system repo, which publishes packages to npm the moment anything reaches its main branch, had a suite spread across four workspaces — the palette contrast gate, the component contrast pairs, the token shape checks — and no workflow that ran any of it. Its workflows directory held a Chromatic job, a publish job and a tag job, and nothing else.
And every one of them was green because I had remembered to run it. That is not a small distinction dressed up as a large one. A suite nothing runs is documentation of an intent, and it degrades exactly like documentation does: silently, at whatever rate the code moves, with no signal at the moment it stops being true. This one happened to still pass when I finally pointed a pipeline at it, which is luck rather than evidence.
Adding the workflow was ten minutes. The part worth keeping is what I did before merging it: a new gate that has only ever been green has been shown to run, not shown to fail, and those look identical in a checks list. So I reintroduced a regression the suite is meant to catch — reverting one chart palette slot to a colour that collides under deuteranopia — watched it exit non-zero with the ratio it objected to, and reverted the revert. A gate I have never seen fail is a gate I have no reason to trust.
The same repo also had a test count that doubled after a build, because its tokens package compiled its own tests into an output directory that the runner did not exclude, and then published that directory. The pipeline gap and the count are two of four findings of the same shape that week, written up in green checks.