@kensio/isolated-testing-style
v1.18.0
Published
An opinionated testing style built on simulated collaborators and randomised data.
Maintainers
Readme
@kensio/isolated-testing-style
An opinionated testing style, packaged as an agent skill. Real collaborators through simulation, isolation from randomised data, and assertions on behaviour.
Every rule in it comes from a specific failure it would have caught, and the failure is written down next to the rule.
Install
Into any agent that reads SKILL.md:
npx @kensio/skills add isolated-testing-styleThat copies the skill directory into .agents/skills/, where Codex, Cursor, Copilot, Gemini CLI and
the other implementations of the specification look for one. Pass --agent claude for
.claude/skills/, --agent copilot for .github/skills/, and --user to install it for every
project at once.
Claude Code also takes it as a plugin:
claude plugin marketplace add KensioSoftware/kensio.ai
claude plugin install isolated-testing-style@kensioOr pin it in a repository as a dependency:
npm install @kensio/isolated-testing-styleEvery skill is also published as a zip on each
release, for a machine with no npm reach.
Unzip it into .agents/skills/ and it is installed.
What it covers
Prefer real collaborators through simulation. A stub asserts that your code called something. A simulator asserts that it called the service correctly. A stub answers whatever you told it to answer. It agrees with your understanding of the API by construction, and cannot find the case where that understanding is wrong.
Take isolation from randomised data. Randomised values from faker mean two tests cannot collide. There is nothing to tear down and no ordering to depend on. A shared environment built the way production is built is closer to production than a minimal one rebuilt per test, and it is faster.
Assert observable behaviour. To prove a value is cached, delete the underlying resource and show the cached value survives. To prove a retry, make the first call fail and the second succeed. Both hold however the code is implemented. That is what makes refactoring safe.
Never pin a value computed by the code under test. Pinning a hash you generated by running the same function only proves the function is deterministic. It keeps passing after the function becomes wrong. Pin against an independent authority, or let a real implementation validate it.
Put test support beside the code. Factories and helpers live in a test-support module next to what they support. Test files hold tests.
Comment test bodies with Given, When and Then, saying why the lines are there. A comment that restates the code adds nothing.
The other two skills
This skill is the philosophy. Two Kensio packages are tools that serve it, each with its own skill:
yulin-aws-simulationcovers@kensio/yulin, an in-process AWS simulator, which is how the first rule is applied to AWS.part-factory-test-datacovers@kensio/part-factory, which builds the randomised objects the second rule depends on.
Part of kensio.ai. Licensed under the Apache License 2.0. See the LICENSE in the repository root.
