Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add the-open-agent/oss-skills --skill testing-strategygit clone --depth 1 https://github.com/the-open-agent/oss-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/the-open-agent/oss-skills/testing-strategy)<a href="https://agentmods.dev/skills/the-open-agent/oss-skills/testing-strategy"><img src="https://agentmods.dev/badge/skills/the-open-agent/oss-skills/testing-strategy.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00114 | $0.02169 |
| Opus 5 | $0.00057 | $0.01085 |
| Sonnet 5 | $0.00023 | $0.00434 |
| Haiku 4.5 | $0.00011 | $0.00217 |
Grade A, and why
testing-strategy scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 199 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing Strategy
For an open-source project, the test suite has a second job beyond correctness: it is the contract that lets strangers change your code safely. Without it, every external PR is a risk you must personally verify, and you become the bottleneck.
The one-command rule
A new contributor must be able to run the full suite in one command, from a fresh clone, with no tribal knowledge:
make test # or: npm test / pytest / cargo test / go test ./...
Requirements, all of them non-negotiable:
- No manual database setup. Use containers, or a file-backed engine in tests.
- No secrets required. Tests needing credentials are skipped by default with a clear message, and run only in CI with secrets present.
- No network by default. A suite that fails on a plane fails in a corporate proxy too, and looks like your bug.
- Deterministic. Seed randomness, freeze time, sort collections before comparing.
- Fast enough to run before every commit. Target under 60 seconds for the default suite; push the slow tests behind a flag.
If setup takes more than git clone && make test, contributions drop measurably. This
is the highest-leverage testing investment an OSS project can make.
The pyramid, and where projects get it wrong
| Level | Share | Runtime | Tests |
|---|---|---|---|
| Unit | ~70% | ms | Pure logic, edge cases, error paths |
| Integration | ~20% | ~s | Component boundaries, real DB/filesystem |
| End-to-end | ~10% | ~10s+ | The two or three flows that must never break |
Two common failure shapes:
- Ice cream cone (mostly E2E) — slow, flaky, and when it fails it doesn't tell you where. Symptom: "just re-run CI" is normal team advice.
- Hourglass (units + E2E, no integration) — every component works, the assembly doesn't. Symptom: bugs are always at the seams.
Test the public API, not internals. Tests bound to private functions turn every refactor into a test rewrite, which teaches contributors that tests are an obstacle.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 199 lines · 114 tokens per session scan A 39ad000b6a07
testing-strategy is a skill published in the GitHub repository the-open-agent/oss-skills (5 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 114 tokens to every session and 2,169 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
skillgrade-graders
Authors deterministic and LLM rubric graders for skillgrade evaluations. Use when creating scoring scripts, writing evaluation rubrics, or combining multiple graders with weighted scoring. Don't use for setting up eval pipelines, configuring eval.yaml defaults, or general test writing.
skillgrade-setup
Sets up and runs skillgrade evaluation pipelines for Agent Skills. Use when initializing eval configurations, running trials, reviewing results, or integrating with CI. Don't use for writing grader scripts, general test authoring, or non-agentic documentation.
qa-test
Run an automated QA flow against a CLI or a locally-served app and report step-level pass/fail with evidence. Use when asked to QA-test a feature, exercise a flow end-to-end, or smoke-test what a PR changed.
verify
Test a behaviour claim as an investigator and report whether the evidence confirms or refutes it — CONFIRMED / REFUTED / INCONCLUSIVE with bash-captured evidence. Use when asked to verify a claim, prove a fix works, or check that a PR does what it says.
fix-failing-tests
Iteratively fix all failing tests until the test suite is green.
bio-pose-validation
Validates docked / generated protein-ligand poses using PoseBusters physical-validity tests, strain energy quantification, geometric checks (planarity, vdW overlap, bond/angle distortion), and pose-energy reasonableness. Use when QC-ing docking results, comparing classical vs ML docking outputs, or filtering pose…