agentleFS
musaJawad004musaJawad004/heron/.claude/skills/test-master/SKILL.md

test-master

Skill1 starsChanged 56 days agoMITView on GitHub

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 frameworks; analyzing coverage gaps; performance testing with k6 or Artillery; security testing with OWASP methods; debugging flaky tests; or working on QA, regression, test automation, quality gates, shift-left testing, or test maintenance.

We split this skill into the rules it gives an agent

12 rules. 3 are common, 8 are distinctive, and 1 is very specific to this project.

  • 3

    Common

    Most of the 11 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If tests fail: classify the failure (assertion error vs.

    line 26
  2. Distinctive:

    If tests are flaky: isolate ordering dependencies, check async handling, add retry or stabilization logic

    line 27
  3. Distinctive:

    Verify coverage targets are met before closing.

    line 29
  4. Distinctive:

    Test happy paths AND error/edge cases (e.g., empty input, null, boundary values)

    line 74
  5. Very specific:

    Use meaningful it('…') descriptions that read as plain-English specifications

    line 76
  6. Distinctive:

    Run tests in CI/CD; document and remediate coverage gaps

    line 78
  7. Distinctive:

    Use production data in tests — use fixtures or factories instead

    line 82
  8. Distinctive:

    Create order-dependent tests — each test must be independently runnable

    line 83
  9. Distinctive:

    Test implementation details (internal method calls) — test observable behaviour

    line 85
  10. Common:

    When creating test plans, provide:

    line 89
  11. Common:

    Test scope and approach

    line 90
  12. Common:

    Test cases with expected outcomes

    line 91

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

// ✅ 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 -->
TopicReferenceLoad When
Unit Testingreferences/unit-testing.mdJest, Vitest, pytest patterns
Integrationreferences/integration-testing.mdAPI testing, Supertest
E2Ereferences/e2e-testing.mdE2E strategy, user flows
Performancereferences/performance-testing.mdk6, load testing
Securityreferences/security-testing.mdSecurity test checklist
Reportsreferences/test-reports.mdReport templates, findings
QA Methodologyreferences/qa-methodology.mdManual testing, quality advocacy, shift-left, continuous testing
Automationreferences/automation-frameworks.mdFramework patterns, scaling, maintenance, team enablement
TDD Iron Lawsreferences/tdd-iron-laws.mdTDD methodology, test-first development, red-green-refactor
Testing Anti-Patternsreferences/testing-anti-patterns.mdTest 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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.