test-software
Skill15 starsChanged 3 months agoMITView on GitHub
Design, implement, and evaluate risk-based software tests across unit, integration, contract, end-to-end, and regression layers. Use when adding tests, reproducing bugs, improving coverage, diagnosing flaky tests, or defining a test strategy; do not use to change production behavior unless the user also requests implementation.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- examples/AGENTS.mdAGENTS.md
- build-backendSkill
- build-frontendSkill
- engineering-loopSkill
- maintain-codex-wikiSkill
- operate-devopsSkill
- orchestrate-engineeringSkill
- review-codeSkill
- review-securitySkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 11 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
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 11
Use the lowest layer that observes the risk without hiding the integration boundary under test.
- Distinctive: line 13
Test behavior rather than private implementation details.
- Distinctive: line 14
Avoid snapshots that hide meaningful assertions.
- Distinctive: line 15
Do not mock the component whose integration contract is under test.
- Distinctive: line 17
Keep fixtures minimal and readable.
- Distinctive: line 18
Do not “fix” flaky tests by adding blind retries or sleeps.
- Distinctive: line 19
Do not claim a regression test without proving it fails against the broken behavior when feasible.
- Distinctive: line 20
Treat tests as potentially state-changing: they may write databases, queues, files, snapshots, browsers, or external sandboxes.
- Distinctive: line 22
Do not run tests against production, shared customer data, or external services without explicit authorization and a verified isolation …
- Distinctive: line 24
Stop when the configured test target or cleanup behavior is ambiguous.
- Distinctive: line 28
Read references/test-strategy.md when choosing test layers or specialized methods, investigating flakes, or planning cross-service coverage.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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
Test Software
Test contract
- Define the behavior, invariant, or defect before selecting a test layer.
- Use the lowest layer that observes the risk without hiding the integration boundary under test.
- Test behavior rather than private implementation details.
- Avoid snapshots that hide meaningful assertions.
- Do not mock the component whose integration contract is under test.
- Control time, randomness, concurrency, and external dependencies explicitly.
- Keep fixtures minimal and readable.
- Do not “fix” flaky tests by adding blind retries or sleeps.
- Do not claim a regression test without proving it fails against the broken behavior when feasible.
- Treat tests as potentially state-changing: they may write databases, queues, files, snapshots, browsers, or external sandboxes.
- Do not run tests against production, shared customer data, or external services without explicit authorization and a verified isolation strategy.
- Stop when the configured test target or cleanup behavior is ambiguous.
Execute and report
Read references/test-strategy.md when choosing test layers or specialized methods, investigating flakes, or planning cross-service coverage.
Build deterministic fixtures, implement the smallest high-value set, and run focused tests repeatedly before broader required checks. Separate product, test, and environment failures.
For a strategy request, return:
- risks in priority order;
- proposed test layer for each risk;
- fixtures and dependencies;
- commands to run;
- coverage intentionally deferred.
For implementation, report focused and broader checks separately.
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.