@boopkit/cap-testing 0.4.0 → 0.5.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@boopkit/cap-testing",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "Jest testing setup and testing skills for AI agents",
   "files": [
     "scaffold/",

package/skills/boop-testing-tdd-light/SKILL.md

@@ -13,3 +13,16 @@ Red → Green → Refactor. Document "before" and "after" states.
 3. **Verify**: Re-run all tests from steps 1-2. Type-checking alone is **not sufficient** — functional tests must pass. Check for regressions in related functionality. Verify from the user's perspective — don't just test internal state. For example, if the feature writes files the user interacts with, verify those files exist and are correct.
 
 Test tools: `npm run test` (Jest), `npm run tester` (CLI — see `npm run tester -- help`). For UI changes, coordinate manual browser testing.
+
+## Picking the right test shape
+
+The cycle above says "write a test." That choice — *which kind of test* — is where TDD-Light most often goes wrong. The easy default ("I'll unit-test the function I just wrote") misses contract bugs at component boundaries. Before writing the test, decide its shape:
+
+- **Unit test** — a pure function or class with no I/O, no callers in this repo that aren't already covered. Hand-crafted fixtures are fine.
+- **Pairwise component test** — the code change introduces or modifies a producer/consumer interface (a function being written has callers in this repo; or the change is a new caller of an existing function). A unit test on either side is not enough — the call-site's actual argument shape must be exercised against the consumer's real behaviour. This is the single most common gap.
+- **Integration test** — data crosses a real boundary (database, HTTP, serialization, filesystem). The boundary must be real; a mock cannot catch a boundary failure.
+- **Route or render test** — a surface (HTML view, REST endpoint, CLI command) where the user-visible output is what matters. The full stack runs; you assert against what the user sees.
+
+For the principles behind these choices — when each shape is required, when each is insufficient, why "tests covered the function's contract in isolation" is not enough at a producer/consumer boundary — see [general testing principles](../boop-testing-testing/SKILL.md). Read it before picking a shape on any task that touches code with callers elsewhere in the repo.
+
+For domain-specific test mechanics in this project's Express stack — fixtures, real-service setup, route helpers, schema contracts — see [Express web tests](../boop-testing-testing-express-web/SKILL.md).