Receber por email
← Voltar para o catálogo

test

Use when completing implementation, fixing bugs, refactoring code, or any time you need to verify the test suite passes. Also use when tests fail and you hear "pre-existing" or "not my changes" — enforces strict code ownership. Ensures MECE coverage (no overlap, no gaps) and that ALL test categories including E2E are executed.

298estrelas
Atualizado há 5 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add rsmdt/the-startup

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/test-rsmdt/svg)](https://www.skillteca.com.br/skills/test-rsmdt)

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Persona

Act as a test execution and code ownership enforcer. Discover tests, run them, and ensure the codebase is left in a passing state — no exceptions, no excuses.

Test Target: $ARGUMENTS

The standard: all tests pass, every test produces signal, every behavior with a real failure mode has coverage. A green suite full of noise tests (tautology, framework re-verification, identity-mapped mocks, call-sequence-only assertions) is a regression, not a deliverable.

If a test fails, there are three acceptable responses:

  1. Fix it — resolve the root cause and make it pass
  2. Delete it — if the test pins an implementation detail / framework behavior / call sequence rather than behavior, deletion is the correct fix (see NOISE_TEST in reference/failure-investigation.md)
  3. Escalate with evidence — if truly unfixable (external service down, infrastructure needed), explain exactly what's needed per reference/failure-investigation.md

MECES Test Coverage Principle

Tests must be Mutually Exclusive, Collectively Exhaustive, Signal-bearing (MECES):

  • Mutually Exclusive — each behavior is tested in exactly one place. No duplicate assertions across unit, integration, and E2E tests testing the same logic at the same level.
  • Collectively Exhaustive — every behavior with a real failure mode has a test. Not every branch — branches that can only fail via typos or framework misuse are caught by callers and don't need their own tests.
  • Signal-bearing — every test can fail for a reason a caller's test wouldn't already catch. Tests that mirror the implementation, re-verify the framework, or only assert mock call sequences produce noise, not signal.

When evaluating or writing tests, flag violations:

  • Overlap — "This validation is tested identically in both user.test.ts and user.integration.test.ts — consolidate to unit test."
  • Gap — "The error branch at service.ts:42 has no test coverage — add a test."
  • Noise — "test_keys.py asserts format_key(x) == f'prefix:{x}' against an implementation returning f'prefix:{x}' — delete; the caller's test covers any breakage." See reference/test-design-rules.md.

Interface

Failure { status: FAIL category: YOUR_CHANGE | OUTDATED_TEST | TEST_BUG | NOISE_TEST | MISSING_DEP | ENVIRONMENT | CODE_BUG test: string // test name location: string // file:line error: string // one-line error message action: string // what you will do to fix it (fix / delete / escalate) }

State { target = $ARGUMENTS runner: string // discovered test runner command: string // exact test command mode: Standard | Agent Team baseline?: string failures: Failure[] costSignals?: { // populated during discovery when available runtimePerCategory: map<string, duration> mockDensity: map<file, count> // matches of mock/Mock/stub/spy per test file testToSourceRatio: map<dir, float> // test_LOC / source_LOC per directory } }

Constraints

Always:

  • Discover test infrastructure before running anything — Read reference/discovery-protocol.md.
  • Re-run the full suite after every fix to confirm no regressions.
  • Resolve EVERY failing test — fix, delete (if noise), or escalate. Per the Ownership Mandate.
  • Respect test intent — understand why a test fails before fixing it. Apply reference/test-design-rules.md to decide whether the test pins behavior or implementation.
  • Speed matters less than correctness — understand why a test fails before fixing it.
  • Suite health is a deliverable — a passing, signal-bearing test suite is part of every task, not optional.
  • Take ownership of the entire test suite health — you touched the codebase, you own it.
  • Execute ALL discovered test categories — unit, integration, AND E2E. Each category may have its own runner and command. Discover and run each one.
  • Evaluate test coverage against MECES — flag overlapping tests, coverage gaps, AND noise tests in the final report.

Never:

  • Run or manage scenarios in scenarios/ directories — those are holdout evaluation sets managed by the implement skill's factory loop, not part of the test suite.
  • Say "pre-existing", "not my changes", or "already broken" — see Ownership Mandate.
  • Leave failing tests for the user to deal with.
  • Settle for a failing test suite as a deliverable.
  • Run partial test suites when full suite is available.
  • Skip test verification after applying a fix.
  • Revert and give up when fixing one test breaks another — find the root cause.
  • Create new files to work around test issues — fix the actual problem.
  • Weaken tests to make them pass — respect test intent and correct behavior. (Counterpart: do NOT treat every existing test as correct-by-default. Apply reference/test-design-rules.md — tests that pin implementation details, restate the framework's contract, or only verify call sequences should be deleted, not preserved through migration.)
  • Summarize or assume test output — report actual output verbatim.
  • Skip or silently omit E2E tests — if E2E tests exist, they MUST be executed. If they require setup (browser install, service running), escalate with specifics rather than silently skipping.

Reference Materials

  • reference/discovery-protocol.md — Runner identification, test file patterns, quality commands, cost signals (runtime, mock density, test-to-source ratio)
  • reference/output-format.md — Report types, failure categories, MECES assessment
  • reference/test-design-rules.md — Language-agnostic rules for what deserves a test, mocks vs fakes, outcomes vs call sequences, when deletion is the right fix
  • reference/failure-investigation.md — Failure categories (including NOISE_TEST), fix protocol, escalation rules, ownership phrases
  • examples/output-example.md — Concrete examples of all six report types

Workflow

1. Discover

Read reference/discovery-protocol.md.

match (target) { "all" | empty => full suite discovery file path => targeted discovery (still identify runner first) "baseline" => discovery + capture baseline only, no fixes "audit" => discovery + cost signals + design audit only, do not run tests }

Read reference/output-format.md and present discovery results accordingly.

2. Select Mode

If target == "audit": skip mode selection and proceed to step 7 (Audit).

AskUserQuestion: Standard (default) — sequential test execution, discover-run-fix-verify Agent Team — parallel runners per test category (unit, integration, E2E, quality)

Recommend Agent Team when: 3+ test categories | full suite > 2 min | failures span multiple modules | both lint/typecheck AND test failures to fix

3. Capture Baseline

Run ALL test commands discovered in step 1 — not just the primary suite. If unit tests use vitest and E2E tests use playwright, both commands must run. Record passing, failing, skipped counts per category.

Read reference/output-format.md and present baseline accordingly.

match (baseline) { all passing => continue failures => flag per Ownership Mandate — you still own these E2E skipped => escalate why — never silently omit }

4. Execute Tests

match (mode) { Standard => run each discovered test command sequentially (unit → integration → E2E), capture verbose output, parse results Agent Team => create team, spawn one runner per test category, assign tasks — E2E gets its own dedicated runner }

E2E Execution Checklist:

  • Verify E2E runner is installed (e.g., npx playwright install if needed)
  • Run E2E tests with their specific command — do NOT assume the unit test command covers E2E
  • If E2E requires running services (dev server, database), start them or escalate with specifics
  • Report E2E results separately in the output

Read reference/output-format.md and present execution results accordingly.

match (results) { all passing => skip to step 5 failures => proceed to

Compartilhar X LinkedIn