testing

Testing in Bun

bun:test is jest-compatible and fast enough that the usual excuses for a thin suite do not apply — a full server start, request and shutdown cycle runs in well under 50 ms (MEASURED, asserted by a shipped test). The interesting decisions are therefore not "which runner" but what to test, at what level, and how to keep it from lying to you.

Two things in this skill are measured behaviour you cannot guess:

1. coverageThreshold keys are silently ignored when singular — your CI gate may be dead right now.
2. spyOn calls through to the original by default — unlike jest.fn(), it is an observer, not a stub.

Both are below, with the measurements.

Test at the component level by default

The single highest-leverage choice. A component (API) test drives your real server over real HTTP:

✗ unit-mocking     call handler(req) directly, mock the service, mock the repo
✓ component        start the real server, POST /users, assert the response and the DB row

Calling a handler as a function skips routing, method matching, body parsing, header handling, the error() hook and the status your framework actually produces. Every one of those has shipped a bug. Worse, a suite built from mocks asserts that your mocks agree with each other — it goes green while the real wiring is broken, which is the failure mode that erodes trust in a suite until nobody reads it.

Reserve isolated unit tests for genuinely algorithmic code: pricing rules, parsers, state machines, backoff policy. Those have many input combinations and no I/O, which is exactly when isolation pays.

The five exit doors — what "assert enough" actually means

"Assert on outcomes, not interactions" is good advice that does not tell you when you are done. This does. A backend request can only affect the world through five doors, so for any feature, ask which it opens and assert on each:

#	Exit door	Assert
1	Response	status, body, headers — the whole object, not one field
2	State change	the row that was written, deleted or left alone
3	External calls	the outgoing request you made, and its shape
4	Message queue	the message published, and its payload
5	Observability	the log line or metric an operator will page on