simplevaad-debug/superskills/test-master

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

1. 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 -->

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