unit-test-philosophylisted

Risk-based unit testing and Allure-readable behavioral spec style for open-agreements. Use when user says "add tests," "test quality," "coverage expansion," "unit test style," or "Allure test spec." Applies when adding/updating tests, expanding coverage, or reviewing test quality across src, integration-tests, and workspace packages.
open-agreements/open-agreements · ★ 34 · Testing & QA · score 81

Install: claude install-skill open-agreements/open-agreements

# Unit Test Philosophy (Open Agreements) ## Security model - This skill is **guidance only** — it does not execute tests or modify code directly. - All test commands are provided for the user or agent to run in their local environment. - No network access, credentials, or external services are required. ## Use this skill when - A request asks to add tests, improve coverage, or harden regressions. - A change touches `src/`, `integration-tests/`, `packages/contracts-workspace`, or `packages/contracts-workspace-mcp`. - You need readable Allure behavior specs and OpenSpec traceability. ## Core philosophy 1. Test highest-risk behavior first. Focus first on mutating flows, parser/validator boundaries, and policy/safety checks. 2. Optimize for regression prevention, not just line coverage. Prioritize branches where failures could produce wrong legal output or unsafe automation behavior. 3. Treat Allure as test style, not test type. Use normal unit/integration tests with Allure labels, steps, and attachments in the same files. 4. Keep spec and test effectively coextensive. If behavior is important enough to test, map it to canonical OpenSpec scenarios or active change-package scenarios. 5. Keep assertions behavior-oriented. Verify user-observable outputs, diagnostics, and mutation outcomes before internals. 6. Make failures easy to debug. Attach structured context for inputs, normalized outputs, and error payloads. ## Repo standards ### Test structure - Use Gi