Testing strategy

Tests one function/module in isolation, dependencies stubbed.

Tests several real units together (e.g. service + DB + parser).

Drives the whole app like a user — browser, server, DB.

Verifies a producer and consumer agree on an API/message shape.

Lower tests = faster, cheaper, less realistic; higher = slower, more confident.

Many unit, fewer integration, very few e2e (Mike Cohn).

static → unit → integration (most) → e2e (Kent C. Dodds).

Integration tests resemble how software is used, with manageable cost.

Inverted pyramid: lots of manual + e2e, few unit tests.

Any stand-in for a real dependency: dummy, stub, spy, mock, or fake.

A placeholder passed to satisfy a signature; never actually used.

Returns canned answers to calls made during the test.

Records how it was called (args, count) while optionally passing through.

A double with pre-programmed expectations; the assertion is on the interaction.

A working but simplified implementation (e.g. in-memory DB).

Mock = scripted calls + assertions; fake = a real (simpler) implementation.

So many mocks the test asserts implementation, not behavior.

Classicist tests state with real objects; mockist tests interactions with mocks.

Three phases: set up, do the thing, check the result.

BDD phrasing of AAA: precondition, action, expected outcome.

Each test verifies a single behavior, not a grab-bag of checks.

Name the behavior, not the method: 'returns 401 when token expired'.

Three ways to produce test data, trading reuse for clarity.

Keep data minimal, intention-revealing, and isolated per test.

Run setup before, and teardown after, every test in a block.

No test depends on another's state or execution order.

Group tests, declare a case, assert on a value.

toBe / toEqual / toMatchObject / toThrow / resolves / rejects.

Create a mock/spy function you control and assert on.

Wrap an existing method to record calls (and optionally replace it).

Replace an entire imported module with a mock.

Take control of time so timers fire instantly and deterministically.

Parameterised test — run the same body over a table of cases.

Reset state/mocks before every test for isolation.

Run the suite once and report coverage (line/branch/function).

A small, complete Vitest file you can drop in and run.

Declare a browser test; assert with auto-retrying expect.

Find elements the way a user (or assistive tech) would.

Web-first assertion — auto-waits and retries until it passes or times out.

Group actions into a named step for readable traces/reports.

Intercept requests and serve a canned response.

Reusable, isolated setup injected per test (page, context, custom).

Capture a replayable trace and screenshot when a test fails.

Run tests in parallel and across multiple browser configs.

A small, complete Playwright spec you can drop in and run.

Different things 'coverage %' can mean — branch is the strict one.

Code can be 100% covered and still be wrong — coverage measures execution, not correctness.

Inject bugs ('mutants') and check your tests catch them — a real quality signal.

Fast · Isolated · Repeatable · Self-validating · Timely.

A test that passes and fails on the SAME code without changes — non-deterministic.

Cause: the test finishes before the async work settles.

Cause: real clocks make tests time-of-day or timezone dependent.

Cause: Math.random / uuid / shuffles make outcomes vary run to run.

Cause: one test leaves state that changes another's result.

Cause: tests hit a real, slow, or rate-limited service.

Cause: CSS transitions race the assertion in e2e tests.

Cause: assertion fires before the UI/data reaches its final state.

Replace arbitrary waits with assertions that retry until the condition holds.

Retries hide flakes; quarantine isolates them. Neither is a fix.

Write a failing test, make it pass minimally, then clean up.

Shines on clear specs and bug fixes; awkward for exploratory UI work.

Asserting on internals (private methods, exact calls) instead of behavior.

Giant auto-generated snapshots that everyone blindly updates.

'Unit' tests that hit a DB, network, or filesystem — really slow integration tests.

A fixture mutated by one test, corrupting others.

Verifying behavior by checking log output instead of real effects.

A test that runs code but never asserts — green even when broken.

if/else, loops, or try/catch deciding what a test asserts.