Use when writing unit, integration or E2E tests, designing a test strategy or framework, finding coverage gaps or load testing with k6 or Artillery. Covers Jest, Vitest, pytest, mocking, flaky tests and security testing with defect reports. For strict test-first workflow see test-driven-development.
Installs into .claude/skills of the current project.
Are you the author of Test Master?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/monoes-test-master)
---
name: test-master
description: "Use when writing unit, integration or E2E tests, designing a test strategy or framework, finding coverage gaps or load testing with k6 or Artillery. Covers Jest, Vitest, pytest, mocking, flaky tests and security testing with defect reports. For strict test-first workflow see test-driven-development."
tags: ["testing","engineering","performance"]
tools: ["monograph_query","monograph_context"]
license: MIT
source: https://github.com/Jeffallan/claude-skills
source_path: "skills/test-master"
source_commit: 882ef55e377dbf9a4dbe496bb41ac6ccd0e555cf
---
# Test Master
Comprehensive testing specialist ensuring software quality through functional, performance, and security testing.
## Core Workflow
1. **Define scope** — Identify what to test and which testing types apply
2. **Create strategy** — Plan the test approach across functional, performance, and security perspectives
3. **Write tests** — Implement tests with proper assertions (see example below)
4. **Execute** — Run tests and collect results
- If tests fail: classify the failure (assertion error vs. environment/flakiness), fix root cause, re-run
- If tests are flaky: isolate ordering dependencies, check async handling, add retry or stabilization logic
5. **Report** — Document findings with severity ratings and actionable fix recommendations
- Verify coverage targets are met before closing; flag gaps explicitly
## Quick-Start Example
A minimal Jest unit test illustrating the key patterns this skill enforces:
```js
// ✅ Good: meaningful description, specific assertion, isolated dependency
describe('calculateDiscount', () => {
it('applies 10% discount for premium users', () => {
const result = calculateDiscount({ price: 100, userTier: 'premium' });
expect(result).toBe(90); // specific outcome, not just truthy
});
it('throws on negative price', () => {
expect(() => calculateDiscount({ price: -1, userTier: 'standard' }))
.toThrow('Price must be non-negative');
});
});
```
Apply the same structure for pytest (`def test_…`, `assert result == expected`) and other frameworks.
## Reference Guide
Load detailed guidance based on context:
<!-- TDD Iron Laws and Testing Anti-Patterns adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
| Topic | Reference | Load When |
|-------|-----------|-----------|
| Unit Testing | `references/unit-testing.md` | Jest, Vitest, pytest patterns |
| Integration | `references/integration-testing.md` | API testing, Supertest |
| E2E | `references/e2e-testing.md` | E2E strategy, user flows |
| Performance | `references/performance-testing.md` | k6, load testing |
| Security | `references/security-testing.md` | Security test checklist |
| Reports | `references/test-reports.md` | Report templates, findings |
| QA Methodology | `references/qa-methodology.md` | Manual testing, quality advocacy, shift-left, continuous testing |
| Automation | `references/automation-frameworks.md` | Framework patterns, scaling, maintenance, team enablement |
| TDD Iron Laws | `references/tdd-iron-laws.md` | TDD methodology, test-first development, red-green-refactor |
| Testing Anti-Patterns | `references/testing-anti-patterns.md` | Test review, mock issues, test quality problems |
## Constraints
**MUST DO**
- Test happy paths AND error/edge cases (e.g., empty input, null, boundary values)
- Mock external dependencies — never call real APIs or databases in unit tests
- Use meaningful `it('…')` descriptions that read as plain-English specifications
- Assert specific outcomes (`expect(result).toBe(90)`), not just truthiness
- Run tests in CI/CD; document and remediate coverage gaps
**MUST NOT**
- Skip error-path testing (e.g., don't test only the success branch of a try/catch)
- Use production data in tests — use fixtures or factories instead
- Create order-dependent tests — each test must be independently runnable
- Ignore flaky tests — quarantine and fix them; don't just re-run until green
- Test implementation details (internal method calls) — test observable behaviour
## Output Templates
When creating test plans, provide:
1. Test scope and approach
2. Test cases with expected outcomes
3. Coverage analysis
4. Findings with severity (Critical/High/Medium/Low)
5. Specific fix recommendations
[Documentation](https://jeffallan.github.io/claude-skills/skills/quality/test-master/)