# Better Testing

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-nicolasyusim-better-codebase-better-testing`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [NicolasYusim](https://agentstack.voostack.com/s/nicolasyusim)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [NicolasYusim](https://github.com/NicolasYusim)
- **Source:** https://github.com/NicolasYusim/better-codebase/tree/main/skills/better-testing

## Install

```sh
agentstack add skill-nicolasyusim-better-codebase-better-testing
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Protect critical behavior with trustworthy tests

Build confidence that meaningful changes are safe. Optimize for defect detection, behavioral contracts, useful failures, and maintainable feedback—not test count or coverage theater.

## Own behavioral protection

Own test strategy, test selection, assertions, fixtures, doubles, suite boundaries, determinism, failure diagnostics, and testability signals.

Treat difficult testing as evidence that may point to an architecture or maintainability problem. Assign the root cause to the appropriate owner rather than prescribing test-only workarounds.

## Review workflow

### 1. Map critical behavior

Identify public contracts, business rules, state transitions, data boundaries, permissions, error behavior, integration points, concurrency or transaction semantics, and high-cost failure paths.

Map each critical behavior to the narrowest trustworthy test layer:

- unit tests for deterministic policy and transformations;
- integration tests for storage, frameworks, queues, files, and service adapters;
- contract tests for consumer/provider or protocol compatibility;
- end-to-end tests for a small set of indispensable user or system paths;
- characterization tests for behavior that must be preserved during refactoring.

Do not infer importance from existing test density. Untested code may be critical; heavily tested helpers may not be.

### 2. Inspect the suite as evidence

Run the narrowest safe test commands available. Inspect failures, duration, retries, skips, quarantine, and environment requirements.

Investigate:

- critical behavior with no executable protection;
- only happy-path coverage where failure modes have meaningful consequences;
- assertions that prove a call happened but not the resulting behavior;
- tests coupled to private methods, call order, internal data structures, or incidental rendering;
- mocks that recreate the implementation and allow integrations to drift;
- snapshots so broad that reviewers cannot see semantic changes;
- non-deterministic time, randomness, shared state, ports, ordering, or external services;
- tests that pass individually but fail in suites or depend on execution order;
- slow setup repeated unnecessarily or end-to-end tests used for cheap policy checks;
- vague names and failures that do not identify the broken contract;
- duplicated fixtures that encode inconsistent domain rules;
- skipped tests with no owner or removal condition.

A flaky-test claim requires repeatable evidence, history, or an identified nondeterministic mechanism.

### 3. Evaluate gaps by risk

A missing test is actionable when all are true:

1. the behavior or contract is important;
2. a realistic regression or failure mode exists;
3. the proposed test would detect it through public behavior;
4. the test can remain more stable than the implementation.

Do not require tests for trivial delegation, generated code, framework internals, or every defensive branch without a credible failure cost.

### 4. Improve the test boundary

Prefer:

1. Stronger assertions on observable results.
2. Focused edge and failure cases for critical rules.
3. Fakes at volatile effect boundaries and real integration below them.
4. Small contract tests shared by multiple implementations.
5. Deterministic control of time, randomness, and external effects.
6. A few end-to-end paths backed by broader lower-level tests.
7. Better production seams when test complexity reveals hidden coupling.

Use mocks to isolate expensive or unsafe effects, not to mirror every internal call.

## Coverage interpretation

Treat line and branch coverage as maps of executed code, not quality targets. A percentage can identify unvisited areas but cannot prove meaningful assertions, representative data, or critical behavior.

Never recommend an arbitrary repository-wide threshold without a risk model and team context.

## Evidence requirements

For each finding, cite the production behavior and relevant test locations. Show:

- the contract or failure mode at risk;
- what the current test proves and fails to prove;
- the smallest test or seam change;
- why it will catch a realistic regression;
- expected test layer, confidence, and maintenance cost;
- a command that verifies the result.

## Implementation rules

When asked to implement:

- add a failing reproduction or characterization test before changing protected behavior;
- assert public results, state, effects, or contracts;
- keep fixtures minimal and explicit;
- avoid production-only hooks added solely for a brittle test;
- remove obsolete tests only after equivalent behavioral protection exists;
- run the focused test first, then the relevant suite;
- report baseline failures separately from new failures.

## Standalone review output

When invoked directly, return:

1. **Critical behavior map** — contracts, risks, and current test layers.
2. **Suite baseline** — exact commands, results, duration or flake evidence when relevant.
3. **Findings** — behavior at risk, current evidence, smallest test or seam change, confidence, and change risk.
4. **Tests not recommended** — tempting low-value coverage and why it was rejected.
5. **Verification** — commands run and gaps requiring environment or data.

If critical behavior has proportionate, trustworthy protection in the inspected scope, state `No actionable testing findings.`

## Guardrails

- Never equate coverage percentage with confidence.
- Never mock the unit so thoroughly that the test restates its implementation.
- Never default to snapshots for behavior requiring semantic assertions.
- Never label a test flaky from one unexplained failure.
- Never add an end-to-end test when a stable lower-level test proves the same contract.
- Never preserve a poor production boundary solely by increasing test indirection.
- Never refactor weakly protected critical behavior before capturing its current intended contract.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [NicolasYusim](https://github.com/NicolasYusim)
- **Source:** [NicolasYusim/better-codebase](https://github.com/NicolasYusim/better-codebase)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-nicolasyusim-better-codebase-better-testing
- Seller: https://agentstack.voostack.com/s/nicolasyusim
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.