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 agentmods add skills/muhammadusmangm/claude-code-best-practices/test-componentnpx skills add MuhammadUsmanGM/claude-code-best-practices --skill test-componentgit clone --depth 1 https://github.com/MuhammadUsmanGM/claude-code-best-practicesWrote 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/muhammadusmangm/claude-code-best-practices/test-component)<a href="https://agentmods.dev/skills/muhammadusmangm/claude-code-best-practices/test-component"><img src="https://agentmods.dev/badge/skills/muhammadusmangm/claude-code-best-practices/test-component.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 | $0.00050 | $0.00501 |
| Opus 5 | $0.00025 | $0.00251 |
| Sonnet 5 | $0.00010 | $0.00100 |
| Haiku 4.5 | $0.00005 | $0.00050 |
Grade A, and why
test-component 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 5d 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.
What it actually says
Test Component
Write tests for an existing component following the project's conventions.
Steps
- Read the component file. Note its props, any hooks it calls, and whether it fetches data.
- Read one existing test file in the same area and mirror its style — imports, render helpers, matcher choices, mock setup.
- Plan 3–5 assertions, in this priority order:
- Renders the expected role/label on mount.
- Responds to user interaction (click, type) with a visible result.
- Handles loading / empty / error states if the component has them.
- Calls the right callback with the right args (if props include callbacks).
- Mock at the network boundary. If the component fetches via a shared
client in
src/api/, add an MSW handler insrc/test/msw/— don't mock the component's internal hooks. - Write the test file next to the component. Name:
<Name>.test.tsx. - Run
npm test -- <Name>once and report pass/fail. Do not fix the component to make the test pass — if a test reveals a bug, stop and tell the user.
Query priority (enforced)
Use in this order, only falling back when the higher option genuinely doesn't apply:
getByRolewith an accessible namegetByLabelTextgetByPlaceholderTextgetByTextgetByTestId— last resort
Rules
- Never call
act()manually. If a test "needs" it, you're testing implementation — rewrite the assertion. - Never
await new Promise(...)to wait for state. UsefindBy*orwaitFor. - No snapshot tests unless the component has a stable, small render surface (icons, formatted strings). Component snapshots rot fast.
- Don't edit the component under test. This skill writes tests only.
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.
- 5d ago First seen · 50 lines · 50 tokens per session scan A 092129a518ce
test-component is a skill published in the GitHub repository MuhammadUsmanGM/claude-code-best-practices (76 stars, last pushed 2mo ago), licensed MIT. It adds 50 tokens to every session and 501 once invoked, about $0.0003 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-30.
Other skills, from other repositories
verify-work
Verify feature, bug, UI, API, mobile, security, or deployment work against acceptance criteria.
frontend-testing
Generate Vitest + React Testing Library tests for frontend components, hooks, and utilities. Triggers on testing, spec files, coverage, Vitest, RTL, unit tests, integration tests, or write/review test requests.
react-testing
Write and review React/TypeScript tests for Sentry's frontend using Jest and React Testing Library. Use when adding or editing tests in static/ (.spec.tsx), writing component/hook tests, mocking API responses with MockApiClient, testing routing or network requests, or when asked to "write a frontend test", "add a…
testing
Best practices for Dart unit tests, Flutter widget tests, and golden file tests.
flutter-bloc-state-management
Implement BLoC/Cubit state, events, transitions, and async concurrency in Flutter. Use for BLoC/Cubit feature logic, debounced/cancellable events, state rendering, or bloc tests—not generic widget-only work.
angular-testing
Write Angular component tests using TestBed, ComponentHarness, and HttpTestingController with proper signal input handling. Use when writing component tests, mocking HTTP calls, or testing signal inputs.