Testing

The gap

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.

Setup

• Vitest as the runner with jsdom environment — same config format as Vite, fast, no Jest compatibility layer needed
• Testing Library for renderHook and waitFor — both are needed for anything that touches React Query
• MSW in node mode for intercepting fetch calls in the hooks — the same library used for browser mocking, just with the node adapter. Configured with onUnhandledRequest: "error" so any fetch without a registered handler fails the test immediately instead of silently passing

What got tested

• Rate limiter — allow/block behavior, remaining count, window reset, IP isolation, bucket isolation. Pure function, fake timers advance the clock without sleeping
• Calendar pure functions — event filtering by day, all-day vs timed event classification, spanning event ordering, and the overlap layout algorithm that assigns column positions so simultaneous events appear side by side
• Vitals formatting — millisecond vs second display, CLS decimal formatting, and the good/needs improvement/poor color thresholds for all five metrics
• Proxy rule matching — the rate limit rule table is tested in isolation without importing the full proxy module, which would pull in next/server and Auth0 and require a Next.js runtime
• useCalendarEvents and useCountdowns — fetch, SSR seeding, error states, and create/update/delete with both optimistic updates and rollback on failure

Testing optimistic updates properly

The 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 overlap layout algorithm

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.

CI and deploy gates

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.

Factory functions

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.