writing-tests
Writing Tests
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:
- What failure would a user or public API consumer notice?
- What is the widest stable boundary that can reproduce it economically?
- Is there an existing integration or E2E workflow that can be extended?
- Would the proposed test fail if the feature entry point stopped calling the tested helper?
- Which edge cases, if any, still justify focused unit tests?