@boopkit/cap-testing 0.3.1 → 0.5.0

package/capability.json

@@ -3,11 +3,34 @@
   "description": "Jest testing setup",
   "type": "development",
   "dependencies": [],
-  "devDependencies": ["jest", "ts-jest", "@types/jest"],
-  "files": ["jest.config.js", "tsconfig.test.json", "tests/"],
-  "skills": ["test.tdd-light.skill.md", "test.testing-express-web.skill.md", "test.testing.skill.md"],
+  "devDependencies": [
+    "jest",
+    "ts-jest",
+    "@types/jest"
+  ],
+  "files": [
+    "jest.config.js",
+    "tsconfig.test.json",
+    "tests/"
+  ],
+  "skills": [
+    "boop-testing-tdd-light",
+    "boop-testing-testing-express-web",
+    "boop-testing-testing"
+  ],
   "scripts": {
-    "test": { "cmd": "jest --runInBand", "description": "Run all tests" },
-    "test:watch": { "cmd": "jest --watch", "description": "Run tests in watch mode" }
+    "test": {
+      "cmd": "jest --runInBand",
+      "description": "Run all tests"
+    },
+    "test:watch": {
+      "cmd": "jest --watch",
+      "description": "Run tests in watch mode"
+    }
+  },
+  "skill_migrations": {
+    "boop-testing-tdd-light": "test.tdd-light.skill.md",
+    "boop-testing-testing-express-web": "test.testing-express-web.skill.md",
+    "boop-testing-testing": "test.testing.skill.md"
   }
 }

package/package.json

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

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

@@ -0,0 +1,28 @@
+---
+name: boop-testing-tdd-light
+description: "When you need to build features, implement changes, or fix bugs, follow the Light TDD Flow. This includes bug fixes found during UAT — write the failing test *before* applying the fix."
+metadata:
+  category: test
+---
+# Light TDD Flow
+
+Red → Green → Refactor. Document "before" and "after" states.
+
+1. **Red**: Run/write tests that expose the gap (failing test for new feature, reproduced bug, baseline metric). Verify that the issue is *observed* and that tests fail for the expected reason. Document the "before" state. **For bug fixes**: write a test that reproduces the exact failure, then confirm it fails for the right reason before touching the implementation.
+2. **Green**: Implement the minimum change. Add any additional tests.
+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).

package/skills/{test.testing.skill.md → boop-testing-testing/SKILL.md}

@@ -1,6 +1,11 @@
+---
+name: boop-testing-testing
+description: "When you need to write, run, or reason about tests in this project."
+metadata:
+  category: test
+---
 # Testing
 
-When you need to write, run, or reason about tests in this project.
 
 ## Philosophy
 

package/skills/{test.testing-express-web.skill.md → boop-testing-testing-express-web/SKILL.md}

@@ -1,6 +1,11 @@
+---
+name: boop-testing-testing-express-web
+description: "When you need to write or run tests for the Express server — services, controllers, middleware, and HTTP routes."
+metadata:
+  category: test
+---
 # Testing: Express App (Web & APIs)
 
-When you need to write or run tests for the Express server — services, controllers, middleware, and HTTP routes.
 
 Parent skill: [testing.skill.md](testing.skill.md) (philosophy, generic approach)
 

package/skills/test.tdd-light.skill.md

@@ -1,10 +0,0 @@
-# Light TDD Flow
-When you need to build features, implement changes, or fix bugs, follow the Light TDD Flow. This includes bug fixes found during UAT — write the failing test *before* applying the fix.
-
-Red → Green → Refactor. Document "before" and "after" states.
-
-1. **Red**: Run/write tests that expose the gap (failing test for new feature, reproduced bug, baseline metric). Verify that the issue is *observed* and that tests fail for the expected reason. Document the "before" state. **For bug fixes**: write a test that reproduces the exact failure, then confirm it fails for the right reason before touching the implementation.
-2. **Green**: Implement the minimum change. Add any additional tests.
-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.