Testing

Design or implement tests for observable behavior, including boundary and failure cases.

Purpose

Design or implement tests for observable behavior, including boundary and failure cases.

Recommended

  • Start from the behavior or contract a user, caller, or dependent system can observe.
  • Preserve the repository's existing test structure, naming, fixtures, runners, and command conventions.
  • Choose the narrowest test level that gives meaningful confidence, then add broader coverage only for behavior that lower-level tests cannot establish.
  • Cover normal, boundary, invalid, failure, and regression cases appropriate to the target behavior.
  • Use deterministic fixtures and test doubles where they isolate a real boundary; keep important integration behavior exercised with realistic collaborators.
  • Separate a failing test's observed evidence from assumptions about the implementation or root cause.
  • Record the exact commands and expected results needed to reproduce and validate the test.

Avoid

  • Testing private implementation details when the public behavior is the contract.
  • Over-mocking dependencies so the test passes while the real integration is broken.
  • Treating a green happy-path test as coverage of boundaries, failures, or concurrency.
  • Changing production behavior merely to satisfy a brittle test without checking the intended contract.

Prompt skeleton

Prompt skeleton — deterministic, no model call

Target behavior
[Describe the observable behavior or contract under test.]

Existing test conventions
[Name the repository's test runner, structure, fixtures, naming, and nearby examples.]

Test level
[Choose unit, component, integration, contract, end-to-end, or another justified level.]

Cases to cover
[List normal and representative behavior cases.]

Boundary and failure cases
[List limits, invalid inputs, errors, empty states, races, and regression cases.]

Fixtures and mocks
[Describe deterministic data and justified test doubles, including real boundaries to keep.]

What not to mock
[Record integrations or behavior that must remain realistic for this test's purpose.]

Commands
[Name the exact test, lint, build, or focused validation commands.]

Expected result
[Define pass criteria and the evidence that the target behavior is covered.]

From templates/testing.md. Placeholders describe what to fill in; nothing here invents project facts.

Evidence

community
  • communityA maintainable test portfolio emphasizes observable behavior, uses appropriate test granularity, and avoids coupling tests unnecessarily to implementation details or excessive mocking.
    The Practical Test Pyramid ↗

Sources