agentsclimarketplace
Sign in

Testing

Skill bricerising/enterprise-software-playbook/skills/testing

Create or expand test suites for microservices (unit, integration, consumer-contract tests for HTTP/gRPC handlers, service flows, event consumers, caches, jobs). Use when adding tests, raising coverage, writing regression tests, or validating consumer-facing behavior. NOT for adversarial code review (use review); NOT for final ship-readiness checks (use finish).From its SKILL.md

Install
npx -y skills add bricerising/enterprise-software-playbook --skill testing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.0 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Testing (Consumer Test Coverage)

Overview

Improve coverage by exercising consumer-visible behavior with infra mocked and behavior preserved.

Inputs / Outputs

Inputs: Spec/contract artifacts from spec or plan (optional but preferred); consumer-facing entrypoints to test. Outputs: Test suite pinning consumer-visible behavior; coverage report. Consumed by finish and review.

Workflow

  1. Read relevant specs (system + service) and map them to consumer-visible flows and invariants.
  2. Identify consumer-facing entrypoints: HTTP/gRPC handlers, public service methods, event consumers, cache/storage adapters, jobs.

GATE: Do not write tests until consumer-facing entrypoints are identified (step 2). If no entrypoints are listed, go back — tests without identified entrypoints tend to test implementation details.

  1. Add tests for success and failure paths that a consumer can observe (invalid input, downstream failures, permissions, timeouts where applicable).
  2. Mock infra boundaries (DB, Redis, network listeners, clocks/timers). Prefer calling handlers/functions directly instead of running real servers.
  3. Run focused coverage and iterate until the target is met (default 80% unless the spec says otherwise).

Minimum viable execution

When context or time is constrained, these are the load-bearing steps:

  1. Read specs and map to consumer-visible flows (step 1) — tests must trace back to spec'd behavior.
  2. Identify consumer-facing entrypoints (step 2) — determines what to test.
  3. Write success + failure path tests (step 3) — both paths, not just happy path.
  4. Run coverage (step 5) — verify the tests actually exercise the code.

Steps that can be cut under pressure: mocking strategy optimization (step 4), coverage iteration beyond first pass.

Chooser (What Test Type Where)

  • New endpoint / handler change: consumer-visible tests — call handler with mocked dependencies, assert response shape + status codes + error handling.
  • Refactor (no behavior change): characterization tests first — pin existing behavior before changing implementation.
  • New event consumer / job: feed mixed payloads (valid, invalid, missing fields, duplicates); assert side effects and idempotency.
  • Boundary change (DB/cache/client): adapter tests — cover happy path, empty/null results, connection failures, timeouts.
  • Cross-service contract change: consumer-contract tests — verify your consumer expectations match the provider's contract.
  • Coverage gap (existing code): start with the riskiest paths — auth/permissions, error handling, input validation, state transitions.

Clarifying Questions

  • What entrypoints are affected (HTTP handler, gRPC method, consumer, job, adapter)?
  • Are there existing specs/contracts that define expected behavior?
  • Is this new behavior (need new tests) or existing behavior (need characterization tests before refactoring)?
  • What is the target coverage level (default: 80%)?
  • What test runner and mocking setup does the project use?

Testing Patterns

  • Handler paths: call handler with mocked service, assert response, metrics, and error handling.
  • Event consumers: feed mixed payload shapes (missing type, struct/list values, invalid entries).
  • Cache/storage: cover cache hit/miss, null/empty results, invalidation behavior.
  • Jobs: use fake timers; cover interval runs and error logging branches.
  • Observability: assert metrics render and logging mixins without external services.
    • Vitest note: if mocked values are referenced by vi.mock factories, use vi.hoisted to avoid init-order bugs.

Guardrails

  • Preserve externally visible behavior and API shapes.
  • Avoid real network/listen calls in unit tests; mock them.
  • Keep tests consumer-focused; do not assert internal implementation details beyond outputs/side effects.

Common failure modes

  • Tests implementation details instead of consumer-visible behavior (e.g., asserting internal method call counts instead of response shape).
  • Defaults to unit tests regardless of context — should use the chooser to pick the right test type.
  • Mocks the thing being tested instead of its dependencies — the test exercises the mock, not the code.
  • Tests happy path only, skips failure modes — missing tests for invalid input, downstream failures, permission denials, and timeouts.

Commands

  • Vitest example: npx vitest run apps/<service>/**/*.test.ts --coverage --coverage.include='apps/<service>/src/**'
  • Generic: cd apps/<service> && npm test -- --coverage

References

Output Template

When applying this skill, return:

  • What consumer-visible behavior is now pinned (happy path + key failure modes).
  • What tests were added/changed (by entrypoint: handler/consumer/job/adapter).
  • Coverage/verification results (commands run + outcomes) and any notable gaps/follow-ups.

What ships with it: 1 file

7.9 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most test skills give in ~1.1k tokens

Counted across 1,201 of the 2,096 authors here whose files we hold, read 2026-09-06

  • Write a failing test before writing codein 43 of 1201, across 36 files
  • Run the full test suitein 36 of 1201, across 35 files
  • Test only one variable per experimentin 34 of 1201, across 17 files
  • Read product marketing context before asking questionsin 34 of 1201, across 14 files
  • Mock external dependenciesin 34 of 1201, across 30 files
  • Define primary, secondary, and guardrail metricsin 33 of 1201, across 16 files
  • Pre-determine sample size before startingin 31 of 1201, across 14 files
  • Test behavior rather than implementationin 31 of 1201, across 29 files
  • Formulate a hypothesis before designing a testin 30 of 1201, across 13 files
  • Document every test hypothesis, variant, and resultin 29 of 1201, across 11 files
  • Use descriptive test function namesin 25 of 1201, across 21 files
  • Commit to the methodology without stopping earlyin 24 of 1201, across 8 files

Said here and by no other author read

  • Map specs to consumer-visible flows and invariants
  • Identify consumer-facing entrypoints before writing tests
  • Mock infrastructure boundaries like databases and network listeners
  • Call handlers or functions directly instead of running servers
  • Pin existing behavior before refactoring code
  • Preserve externally visible behavior and API shapes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.