A Testing Setup Checklist for 2026

Last updated 2026-03-31 | SPUNK13 LLC | spunk.bet

A test suite either gets trusted or gets ignored, and that is decided by setup choices made in the first week. Work through this list once and the suite stays useful.

Pick the runner your ecosystem has converged on

• JavaScript and TypeScript: Vitest for anything using Vite, which is most new projects — it shares the config, handles TS and ESM natively, and watch mode is near-instant. Jest remains fine for existing projects; migrating is rarely worth it on its own.
• Python: pytest. Fixtures over setUp methods, -x to stop at the first failure, -k to select by name, --lf to rerun only last failures.
• Go: the standard library, with table-driven subtests and t.Parallel().
• Browser end-to-end: Playwright. Auto-waiting removes the sleep-based flakiness that defines the alternative.

Get the shape right

Aim for many fast unit tests, a meaningful layer of integration tests that exercise real boundaries, and a small number of end-to-end tests covering the flows that lose money if broken — sign-up, checkout, login. Inverting that gives you a slow suite that fails for reasons unrelated to your change. Use a real database in integration tests via Testcontainers rather than mocking your data layer; mocked database tests pass while the query is wrong.

Make failure messages do the work

A test named test_user_2 that asserts assert result == expected tells a future reader nothing. Name tests after the behaviour (rejects_expired_token), assert one thing, and include context in the assertion message. When a test fails at 2am, the message is the entire debugging experience.

Control flakiness deliberately

A suite with a 2% flake rate and 300 tests fails roughly every other run for no reason, and within a month people rerun failures without reading them. Fix the causes rather than adding retries: freeze time instead of sleeping, seed randomness, isolate tests so they do not share database state, and never depend on execution order — run with a random seed to prove it. Quarantine a persistently flaky test into a separate non-blocking job with a deadline for fixing it, rather than leaving it to erode trust in the whole suite.

Coverage: a diagnostic, not a target

Coverage tells you what is untested, not whether the tests are good. A 100% covered codebase can have assertions that check nothing. Useful practice: measure it, look at which files are near zero, and require that new code does not lower the number. Enforcing an absolute percentage produces tests written to satisfy the metric. If you want to know whether the tests are meaningful, mutation testing (Stryker, mutmut) answers that question directly, though it is slow enough to run nightly rather than per commit.

CI configuration that keeps the suite fast

• Run unit tests on every push; run the full end-to-end suite on pull requests and on main.
• Shard across parallel jobs when the suite passes about ten minutes — most runners support splitting by timing data.
• Cache dependencies keyed on the lockfile hash, and use the frozen install so a stale cache cannot change the tree.
• Fail fast on lint and type checks before spending minutes on tests.
• Upload artifacts on failure — Playwright traces, screenshots and server logs turn "flaky in CI" into a fixable bug.
• Set a job timeout. A hung test that runs for six hours is a billing event.

The checks worth adding once

A smoke test that hits the deployed environment after release. A test that fails when a database migration is missing. And a periodic scheduled run on main, so you learn that an external dependency broke your suite before a developer does.