From 6cc2a1d08a6a6ee10f9acee9b967f36827c0a27e Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Fri, 22 May 2026 14:29:29 -0500 Subject: docs(skills): add a category-exception protocol to add-tests MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Normal/Boundary/Error rule forced all three categories on every function, including pure adapters, generated code, and framework glue where a category would only re-test the framework. Step 7 now lets you skip a category in those cases, as long as you state and justify the skip in the plan and cover the behavior at integration or E2E level — a stated decision, never a silent omission. Step 12 points back to it. The companion audit item about a missing typescript-testing.md reference turned out moot: that ruleset now exists and add-tests already references it correctly. --- add-tests/SKILL.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/add-tests/SKILL.md b/add-tests/SKILL.md index 3dd91fc..23b3a59 100644 --- a/add-tests/SKILL.md +++ b/add-tests/SKILL.md @@ -42,6 +42,7 @@ Work through four phases in order. Do not skip phases. 6. Present a test plan as a markdown table with columns: File, Functions, Current Coverage, Proposed Tests, Priority (P0/P1/P2). 7. For each proposed test, specify: target function, category (Normal / Boundary / Error), one-line description, and any mocking required. All three categories are required per function — see `testing.md` for category definitions. + - **Category exception.** Some functions don't earn all three: pure adapters, generated code, tiny pass-through wrappers, and framework glue, where a Normal/Boundary/Error case would only re-test the framework or the language. When you skip a category, say so in the plan and state why ("Error: N/A — delegates to the ORM, which owns the failure path"), and cover the behavior at the integration or E2E level instead. Skipping is a stated decision in the plan, never a silent omission. 8. **Surface the coverage choice for parameter-heavy functions.** If a function has 3+ parameters with multiple values each, category-based cases (Normal/Boundary/Error per parameter individually) miss interaction bugs, while exhaustive cases explode combinatorially. Ask the user, citing specific numbers: > "Function `` has N parameters (M^N = Y exhaustive combinations). Pairwise or exhaustive? @@ -62,7 +63,7 @@ Work through four phases in order. Do not skip phases. integration/ # Multi-component workflows ``` 11. Follow the naming convention: `test____`. Example: `test_satellite_calculate_position_null_input_raises_error`. -12. Write all three test categories (normal, boundary, error) for every function in the approved plan. Be thorough with edge cases — cover boundary conditions, error states, and interactions that could realistically fail. +12. Write all three test categories (normal, boundary, error) for every function in the approved plan, honoring any category exceptions documented in step 7. Be thorough with edge cases — cover boundary conditions, error states, and interactions that could realistically fail. 13. Use language-specific standards: - **Python:** Follow `python-testing.md` — use `pytest` (never `unittest`), fixtures for setup, `@pytest.mark.parametrize` for category coverage, `@pytest.mark.django_db` for DB tests, `freezegun`/`time-machine` for time mocking. - **TypeScript/JavaScript:** Follow `typescript-testing.md` — use Jest + React Testing Library, query priority (`getByRole` > `getByLabelText` > `getByText` > `getByTestId`), `waitFor` for async, type-safe test helpers in `tests/helpers/`. -- cgit v1.2.3