Consumer Test Coverage
Overview
Improve coverage by exercising consumer-visible behavior with infra mocked and behavior preserved.
Workflow
- •Read relevant specs (system + service) and map them to consumer-visible flows and invariants.
- •Identify consumer-facing entrypoints: HTTP/gRPC handlers, public service methods, event consumers, cache/storage adapters, jobs.
- •Add tests for success and failure paths that a consumer can observe (invalid input, downstream failures, permissions, timeouts where applicable).
- •Mock infra boundaries (DB, Redis, network listeners, clocks/timers). Prefer calling handlers/functions directly instead of running real servers.
- •Run focused coverage and iterate until the target is met (default 80% unless the spec says otherwise).
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.mockfactories, usevi.hoistedto avoid init-order bugs.
- •Vitest note: if mocked values are referenced by
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.
Commands
- •Vitest example:
npx vitest run apps/<service>/**/*.test.ts --coverage --coverage.include='apps/<service>/src/**' - •Generic:
cd apps/<service> && npm test -- --coverage
References
- •Specs and contracts as test sources:
spec-driven-development - •Telemetry verification (when tests cover boundary logging/metrics):
apply-observability-patterns
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.