test-boundarylisted

Choose the unit/integration boundary — which collaborators to substitute, when to use a real dependency, and how to package integration dependencies. Use when deciding whether a test should be unit or integration, or picking between container, library, and in-memory packaging for a dependency.
ecoma-io/touchstone · ★ 1 · AI & Automation · score 60

Install: claude install-skill ecoma-io/touchstone

# Test Boundary Base principles: [test-isolation-base](../test-isolation-base/SKILL.md) The boundary is what makes a unit test a unit test. Getting it wrong silently changes the tier. - **Substitute project-internal collaborators** — modules, packages, and services this repository owns. Their contracts you control; their behaviour you are deliberately holding still. - **Integration tier** — the _interaction_ is what is under test: two real pieces, and the contract between them is the thing that can break. Real filesystem, real database, real HTTP. - "Mocking it was annoying" is never the reason to cross into integration; "this seam is the behaviour I am pinning" is. ## Picking the packaging for integration dependencies Three tiers of substitute, not two: | Tier | Startup | Semantics | | -------------------------------- | --------- | ---------------- | | Real engine, container packaging | 1.6–3.3 s | the reference | | Real engine, library packaging | 9–160 ms | identical | | A reimplementation | 0–8 ms | 20–83% agreement | The middle tier is the one most advice skips. A real process started by a library instead of a daemon is where "faster" actually lives. Library packaging is the correct default. Per-language: [TypeScript](references/typescript.md)