kit-testing-rules
Skill0 starsChanged 20 days agoMITView on GitHub
Testing conventions for this project. Use when reading, writing, or reviewing files matching `**/*.test.*`, `**/*.spec.*`, `**/test/**`, `**/tests/**`, `**/__tests__/**`. Do not use for other files.
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Use the project's existing test framework, helpers, fixtures, and file layout.
- Distinctive: line 9
Test observable behavior through public interfaces, not private implementation details.
- Distinctive: line 12
Keep tests deterministic: control time, randomness, network, and ordering.
- Distinctive: line 13
Prefer real collaborators or the project's existing fakes over new mocks.
- Distinctive: line 15
When fixing a bug, add a test that fails without the fix.
- Distinctive: line 16
Never delete, skip, or weaken an existing test to make a change pass without explaining why to the user.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Testing conventions
- Use the project's existing test framework, helpers, fixtures, and file layout. Do not add a new framework.
- Test observable behavior through public interfaces, not private implementation details.
- Give each test one clear reason to fail. Name it after the behavior it checks.
- Cover the changed behavior, its edge cases, and its failure paths, not only the happy path.
- Keep tests deterministic: control time, randomness, network, and ordering. Do not depend on test execution order.
- Prefer real collaborators or the project's existing fakes over new mocks. Mock only at slow or external boundaries.
- Clean up files, processes, and global state that a test creates.
- When fixing a bug, add a test that fails without the fix.
- Never delete, skip, or weaken an existing test to make a change pass without explaining why to the user.
In this repository21 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- kit-code-reviewSkill
- kit-commitSkill
- kit-debuggingSkill
- kit-documentationSkill
- kit-feature-implementationSkill
- kit-pull-requestSkill
- kit-refactoringSkill
- kit-security-auditSkill
- kit-test-writingSkill
- kit-typescript-rulesSkill
- kit-code-reviewSkill
- kit-commitSkill
- kit-debuggingSkill
- kit-documentationSkill
- kit-feature-implementationSkill
- kit-pull-requestSkill
- kit-refactoringSkill
- kit-security-auditSkill
- kit-test-writingSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.