A test is a claim, written in code, that some behaviour holds. Two failures account for nearly everything that goes wrong with a suite. A test can pass while the code is broken, because it never really checked — a forgotten await, an assertion that could not fail, a line counted as covered merely for running. Or it can fail while the code is fine, because it was pinned to an internal detail somebody was entitled to change. Almost every piece of testing advice is an attempt to avoid one without falling into the other.
Each chapter opens with the short version. Tap one to read the detail.
What to test, and where
~2 min
The useful question is never "is this tested" but "what defect would this catch, and what will it cost me every week?" Push confidence downward: many fast tests over logic, fewer across real boundaries, a handful of end-to-end journeys. A suite shaped the other way up is slow, flaky and hard to diagnose.
What a test is, and what an assertion proves
~3 min
A test passes when its function returns without throwing — so a test with no assertions passes, and one you have never watched fail may be checking nothing. Picking between toBe, toEqual and toStrictEqual matters; writing an assertion capable of failing matters far more.
Isolation: why it passes alone and fails in the suite
~2 min
Hooks exist so cleanup runs even when a test fails — teardown written at the bottom of a test body is skipped the moment an assertion throws. Outer hooks wrap inner ones, and every describe body runs before any test does, which is where shared state usually leaks in.
Asynchronous tests, and controlling the clock
~2 min
The runner only waits for what you hand it. Forget to return or await, and the test finishes before the assertion runs — reporting green. Fake timers make a delay instant, but advancing the clock does not run queued promise callbacks.
Test doubles: what to replace, and what it costs
~2 min
Replace what you do not control — the network, the clock, a third-party service — and stop there. A double standing in for your own logic makes the test pass by construction. Asserting how a function was called, rather than what came out, couples the test to the implementation you were free to change.
Measures that feel like proof, and are not
~2 min
Coverage counts lines executed, never behaviour verified — a test that asserts nothing at all can report 100%. A snapshot detects change, not correctness, and its first run always passes, so all of its value sits in the diff you review.
The runner: environment, configuration and the Jest/Vitest split
~2 min
Most "it works in my app but not in tests" problems are environment or transform problems rather than test problems. The environment defaults to Node, so document is not defined means you asked for the wrong one, and dependencies are left untransformed by default.
Component tests: query the way a user would
~2 min
Query by role and accessible name first and test ids last, so a refactor that changes nothing a user perceives cannot break the test. getBy throws, queryBy returns null, findBy retries — and waitFor only retries while its callback throws.
End-to-end: locators, auto-waiting and retrying assertions
~2 min
A Playwright locator is a description, not an element — it re-finds the element each time you act, and the action waits until it is usable. The assertion that retries and the assertion that does not look nearly identical, and choosing wrong is the classic source of end-to-end flake.
Flaky tests, and running the suite for real
~2 min
A flaky test is one whose result changes with no change to the code under test. Retries turn the build green and the signal worthless. The causes are nearly always leaked state, real time, or two workers competing for one resource.
Written by Keentune. We are not affiliated with or endorsed by the organizations whose documentation informs this guide, and any linked sources belong to their respective owners.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.