Writing Tests

Apply this skill when the user explicitly requests new tests or when existing tests, fixtures, or snapshots need updates for feature work, bug fixes, refactors, or PR preparation. Do not add new tests, including new test cases in existing files, unless the user explicitly requests them. A request to review tests does not authorize changing them.

The purpose of a test is confidence that a workflow or contract works for a Studio user, CLI user, package consumer, or renderer consumer.

Test the feature at the widest stable boundary that gives useful confidence. Prefer one complete integration workflow; use focused unit tests for genuinely complex logic and E2E tests for critical cross-process workflows.

Test count, assertion count, file count, and coverage percentage are not quality metrics. One rendered frame, final artifact, or persisted-source assertion can give more confidence than many narrow unit assertions.

A test that stays green when the feature is disconnected is not useful primary coverage. For a user-facing or cross-layer feature, a private helper unit test must not be the only coverage.

Choose the boundary before writing the test

Answer these questions first: