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 doancan/mags --skill testing-strategygit clone --depth 1 https://github.com/doancan/magsWrote 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/doancan/mags/testing-strategy)<a href="https://agentmods.dev/skills/doancan/mags/testing-strategy"><img src="https://agentmods.dev/badge/skills/doancan/mags/testing-strategy/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/doancan/mags/testing-strategy"><img src="https://agentmods.dev/badge/skills/doancan/mags/testing-strategy.svg" alt="Reviewed on agentmods" width="80" 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.00058 | $0.02131 |
| Opus 5.5 | $0.00023 | $0.00852 |
| Sonnet 5.5 | $0.00012 | $0.00426 |
| Haiku 4.5 | $0.00006 | $0.00213 |
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 1mo 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 — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing Strategy
Test Pyramid
Follow the test pyramid distribution to balance speed, cost, and confidence:
- Unit Tests (70%): Test individual functions, methods, and classes in isolation. These run in milliseconds, have no external dependencies, and form the foundation of the test suite. Every public function should have at least one unit test.
- Integration Tests (20%): Test the interaction between two or more components, including database queries, API endpoints, and service-to-service communication. Use real dependencies where practical (e.g., test containers for databases) and mocks only for external third-party services.
- End-to-End Tests (10%): Test complete user workflows through the full stack. Keep these focused on critical paths only: signup, login, core business transactions, and payment flows. E2E tests are slow and brittle; do not use them to cover edge cases that unit tests can handle.
Rationale: Inverting the pyramid (heavy E2E, light unit) leads to slow CI pipelines, flaky builds, and poor developer experience. If a test can be written at a lower level, write it there.
Coverage Targets
Set coverage targets based on module criticality, not a single global number:
- Authentication and payment modules: 90%+ line coverage, 85%+ branch coverage. These modules handle security and money; gaps here create real risk.
- Core business logic: 80%+ line coverage, 75%+ branch coverage. This includes domain models, validation rules, and business workflows.
- API controllers and route handlers: 70%+ line coverage. Focus on testing request validation, authorization checks, and response formatting.
- Utility functions and helpers: 60%+ line coverage. Simple utilities often have obvious behavior, but still test edge cases (empty input, null, boundary values).
- Generated code, type definitions, and configuration: Exclude from coverage metrics. Do not inflate coverage numbers by testing boilerplate.
Enforce coverage in CI as a ratchet: coverage can go up but never down. Use --coverage-threshold flags or equivalent to fail the build if coverage drops below the current baseline.
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.
- 1mo ago First seen · 127 lines · 58 tokens per session scan A 6f5bdb989efe
testing-strategy is a skill published in the GitHub repository doancan/mags (3 stars, last pushed 8mo ago), licensed MIT. It adds 58 tokens to every session and 2,131 once invoked, about $0.0002 per session on Opus 5.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
testing-assistant
Manages testing lifecycle including unit tests, integration tests, validation, and quality assurance.
ios-testing-patterns
XCTest and XCUITest execution workflows and flaky test detection patterns.
verify
Verification loop — lint -> typecheck -> unit -> integration -> e2e.
check-coverage
Comprehensive assessment of Unit / Integration / E2E three-layer test coverage, identify gaps and provide actionable recommendations.
test-commander
Generate unit, integration, E2E, and visual regression tests following the Testing Trophy methodology (80% integration). Covers Vitest/Jest, Testing Library, Playwright, MSW for API mocking, snapshot strategy, visual regression (Chromatic/Percy/Playwright), test factories with Faker, and CI sharding. Use when user…
proof-strategy
Produce a test strategy for a project or feature — risk map, test type decisions, coverage targets, CI config. Use when asked to "create test strategy", "what should we test", "testing plan", or "improve test coverage".