mcpField
T
test-master

test-master

github.com/farmageTesting & quality218333 installsUpdated 5w ago
Repository

About test-master

test-master is a testing skill for planning and carrying out functional, performance, and security testing. It guides test creation, failure analysis, coverage checks, and reporting with actionable recommendations.

Key features

  1. 01Plan functional, performance, and security tests
  2. 02Write tests with specific assertions
  3. 03Classify failures and address flakiness
  4. 04Review coverage and identify gaps
  5. 05Report severity and recommended fixes

Use cases

  1. 01Build a test strategy for a feature
  2. 02Investigate failing or flaky tests
  3. 03Check coverage before release
  4. 04Summarize QA findings for a team

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/farmage/opencode-skills --skill test-master

After installing, type/test-masterin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
automation-frameworks.md
e2e-testing.md
integration-testing.md
performance-testing.md
qa-methodology.md
security-testing.md
tdd-iron-laws.md
test-reports.md
testing-anti-patterns.md
unit-testing.md

Details

From the project README

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:

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

Comments

Markdown supported