Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/jnPiyush/AgentXnpx agentmods add skills/jnpiyush/agentx/testingWrote 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/jnpiyush/agentx/testing)<a href="https://agentmods.dev/skills/jnpiyush/agentx/testing"><img src="https://agentmods.dev/badge/skills/jnpiyush/agentx/testing/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/jnpiyush/agentx/testing"><img src="https://agentmods.dev/badge/skills/jnpiyush/agentx/testing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Memory Poisoning · line 194 Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.Fix: Protect agent memory and state from modification by untrusted content. Use read-only memory for critical instructions and validate all state changes.
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.00049 | $0.02068 |
| Opus 5.5 | $0.00020 | $0.00827 |
| Sonnet 5.5 | $0.00010 | $0.00414 |
| Haiku 4.5 | $0.00005 | $0.00207 |
Grade A, and why
testing 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 7d 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 — 241 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing
Purpose: Language-agnostic testing strategies ensuring code quality and reliability. Goal: 80%+ coverage with 70% unit, 20% integration, 10% e2e tests. Note: For language-specific examples, see C# Development or Python Development.
When to Use This Skill
- Writing unit tests for new code
- Designing integration test suites
- Implementing end-to-end test automation
- Measuring and improving test coverage
- Setting up continuous testing in CI/CD pipelines
Prerequisites
- Testing framework installed (pytest, Jest, xUnit, etc.)
- CI/CD pipeline for automated test execution
Frontier Execution Boundary
Inside a Frontier quality loop or review, use this skill to design and author
tests, not execute suites. Test execution, coverage and adversarial test runs
wait until the loop completes and the owning agent explicitly asks the user.
No answer or a decline means not run. Use .github/AGENT-PROTOCOL.md section
1.4 for the consent procedure.
The execution recipes below apply to explicitly approved, separate testing tasks and CI/release jobs. They do not override the in-loop/review prohibition. Do not claim pass counts or coverage for tests that were only written or read.
Rationalization Table
If you find yourself thinking one of these, push back against it. These are the common ways agents and humans skip the discipline.
| Rationalization | Reality |
|---|---|
| "The change is small, tests are overkill." | Small changes hide the highest-leverage regressions because reviewers under-scrutinize them. Add at least one regression test per behavioral change. |
| "I'll add tests after the feature works." | Tests written after code are shaped to pass current code, not to specify behavior. Write the failing test first; confirm it fails for the expected reason; then code. |
| "This code is too hard to test, so we'll skip it." | "Hard to test" almost always means "badly factored". Refactor for testability instead of waiving the requirement. |
| "Coverage is at 80%, we're fine." | Coverage measures lines, not behavior. Branches, error paths, and boundary inputs can all be untested at 80% line coverage. Inspect what is covered, not just the number. |
| "The test is flaky, just rerun it." | A flaky test is a bug report. Fix the timing, the shared state, or the assertion. Do not retry until green. |
| "This is a refactor, behavior is identical." | Then the existing tests must all stay green without modification. If you had to edit tests to keep them green, the refactor changed behavior. |
What ships with it
7 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- references/frameworks-and-resources.md 901 B
- references/test-org-ci-pitfalls.md 1.9 KB
- references/test-type-examples.md 3.9 KB
- scripts/check-coverage.ps1 3.5 KB runs code
- scripts/check-coverage.sh 3.3 KB runs code
- scripts/check-test-pyramid.ps1 3.5 KB runs code
- scripts/scaffold-playwright.py 12 KB runs code
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.
- 7d ago Changed · -15 lines cd8deb74305e
- 20d ago Changed 898fa89fa484
- 1mo ago Changed 4c97f7908d56
- 1mo ago First seen · 256 lines · 49 tokens per session scan A 1ab0f0f1a25e
testing is a skill published in the GitHub repository jnPiyush/AgentX (16 stars, last pushed 3d ago), licensed Apache-2.0. It adds 49 tokens to every session and 2,068 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-09-03.
Other skills, from other repositories
test-master
Generates test files, creates mocking strategies, analyzes code coverage, designs test architectures, and produces test plans and defect reports across functional, performance, and security testing disciplines. Use when writing unit tests, integration tests, or E2E tests; creating test strategies or automation…
axiom-testing
Use when writing ANY test, debugging flaky tests, making tests faster, or choosing Swift Testing vs XCTest. Covers unit tests, UI tests, async testing, test architecture.
designing-tests
Designs and implements testing strategies for any codebase. Use when adding tests, improving coverage, setting up testing infrastructure, debugging test failures, or when asked about unit tests, integration tests, or E2E testing.
testing-blocks
Use this when you have made AEM Edge Delivery Services code changes to blocks, scripts, or styles and need to validate them before opening a pull request. Covers unit testing for utilities and logic, browser testing with Playwright, linting, and guidance on what to test and how.
JMeter Load Testing
Load and performance testing skill using Apache JMeter, covering test plans, thread groups, assertions, listeners, timers, and distributed testing.
testing-patterns
Testing strategy: pyramid, AAA, mocks/fakes/stubs, flaky tests, coverage. Triggers: test, fixture, mock, stub, e2e, TDD, Playwright, Cypress, flaky, coverage, property-based.