Skip to content

name: extreme-testing-rigor description: Use when implementing, modifying, or reviewing application or game logic that needs rigorous verification, including tests, coverage, invariants, boundary cases, fault injection, fuzzing, and mutation testing.

Extreme Testing Rigor

Apply safety-critical testing discipline proportionately to the change. A feature, logic branch, or bug fix is not complete until its behavior has been verified. Prefer the smallest verification that proves the relevant risk, but do not claim checks that the project cannot run.

Start With The Project

  1. Read AGENTS.md and inspect the existing test and verification tooling.
  2. Use the project's documented commands and package manager. In Profectus, use mise run <task>; run mise run check before finishing a change.
  3. Determine whether a test harness exists before adding tests. This project currently has no automated test suite, so do not pretend coverage, fuzzing, mutation testing, or target-device testing was performed when it was not.
  4. State any verification gap explicitly and, when appropriate, add focused tests or testable boundaries rather than relying on manual reasoning.

Design For Testability

  • Keep state transitions, calculations, validation, and recovery logic in small deterministic functions where practical.
  • Separate side effects such as storage, time, randomness, network requests, browser APIs, and rendering from core logic through narrowly scoped interfaces or injected dependencies.
  • Preserve production parity: test the same behavior and build configuration that ships. Do not create test-only paths which change production semantics.
  • Add executable invariants at critical state boundaries where an invalid state would corrupt progress, violate security, or cause hard-to-diagnose failure.
  • Handle supposedly impossible states defensively. Assertions must make an assumption visible and fail clearly in development or testing; they must not silently hide invalid input or state.

Verification Plan

For each behavior change, identify and exercise the relevant cases:

  • The intended success path and every changed conditional outcome.
  • Boundary values, including immediately below, at, and immediately above each meaningful threshold.
  • Empty, missing, malformed, duplicate, stale, and oversized inputs where the boundary accepts external or persisted data.
  • State-machine transitions, repeated operations, cancellation, and recovery after partial completion.
  • Failure of each external dependency, including a one-time failure and a persistent failure when the operation has meaningful cleanup or recovery.
  • Resource lifecycle correctness for timers, event listeners, subscriptions, abort controllers, and browser resources.

For compound decisions, ensure tests demonstrate that each condition can independently change the result when that level of coverage is feasible.

Fault Injection And Recovery

When code depends on storage, network, assets, authentication, clocks, random sources, or other services, make failures injectable and test them:

  1. Fail each call in turn to find cleanup and error-handling gaps.
  2. Fail all calls starting at each meaningful point to verify stable degraded behavior.
  3. For persisted game or application state, test invalid, truncated, and corrupted snapshots. The system must either repair, reject, or safely reset the state without crashing or retaining an inconsistent state.

Advanced Verification

Use these techniques when supported by the repository and justified by risk:

  • Coverage-guided or randomized action fuzzing for complex interaction flows; retain minimal, reproducible inputs that expose new behavior or failures.
  • Metamorphic tests: compare logically equivalent operation sequences and require equal results.
  • Mutation testing: invert decisions, remove transitions, or alter calculations and confirm the test suite fails. A surviving mutation identifies a test gap.
  • Runtime sanitizers, leak tracking, race detection, and production-equivalent target-platform testing for code where the platform can change behavior.

Completion Checklist

  • [ ] The change's success, failure, and boundary paths are verified.
  • [ ] Important state invariants and cleanup responsibilities are explicit.
  • [ ] External failures and malformed persisted data are handled safely where applicable.
  • [ ] New tests use existing project conventions and run successfully.
  • [ ] Project-required checks have run successfully.
  • [ ] Any unavailable verification, coverage, or target-platform checks are reported as gaps rather than assumed complete.