Jest Testing

Use this capability whenever a change touches Jest — its configuration, its API, its command line, or the way a suite is transformed and isolated. It owns the runner layer: which Jest API, which option, which file, which flag, and what each one costs.

It does not own what to test. Whether a behavior deserves a test at all, how a describe block and a case are named, whether an assertion pins behavior or implementation, and whether something belongs in a unit test rather than an integration or end-to-end one all belong to a unit-testing capability, which is runner-agnostic and applies whether a project runs Jest, Vitest, or Node's built-in runner. This skill assumes those decisions are made and says how Jest carries them out. Where a rule here has a counterpart there, this skill states the Jest mechanism and names the other as owner.

It also does not own the framework an integration sits inside. That Next.js has a build config to wrap, or that an Expo app has a Metro config, is a framework fact owned by that framework's own capability; what the Jest side of that wiring looks like is owned here.

Version discipline. Jest's option surface moves between majors, and Jest 30 removed a decade of aliases in one release: toBeCalledWith, toThrowError, jest.genMockFromModule, jest.SpyInstance, and jest --init are all gone rather than deprecated. Options also behave differently than their names suggest — waitForUnhandledRejections defaults to false, not on. Every version-sensitive statement here names what it was verified against and links the upstream page it was checked against, and where a surface is known to move the rule is a lookup — consult Jest — Configuring Jest for the installed version — rather than a frozen option name. Treat an unversioned claim about a Jest option, in this skill or anywhere else, as suspect.

Verified against jest 30.4.2 — Jest — Getting Started — published to npm on 2026-05-09 and still latest as of 2026-08-01, whose engines.node is ^18.14.0 || ^20.0.0 || ^22.0.0 || >=24.0.0.

Out of scope. Vitest, Node's built-in test runner, and Bun's are named only where the honest answer to "should this project run Jest at all" is no. React Testing Library's own query and assertion conventions belong to a component-testing capability; only its Jest-side wiring is covered here.

Guidelines:

• MUST resolve a version-sensitive question against the installed Jest's own documentation rather than from memory, and state the version the answer came from.
• MUST ask Jest itself — --listTests, --showConfig — what a configuration actually selects, rather than reasoning about the pattern; its glob and regex matching does not read off the page.
• SHOULD type every mock against the interface it replaces; a bare jest.fn() accepts and returns anything, so it survives a signature change that should have broken the test.