maxedapps Awesome Tests
Critical rules
- Before any activity, read
references/test-quality-gates.mdfully and apply its contextual gates. - Optimize meaningful confidence per maintenance cost, not test count or coverage theater.
- Map every test to an observable behavior or material risk and its intended failure signal.
- Prefer public or user-visible contracts over implementation details. Assert exact text, order, calls, or snapshots only when they are contractual rather than incidental.
- Require deterministic, isolated tests. Follow repository conventions and use the cheapest layer with sufficient fidelity.
- Treat counts, coverage, mocks, snapshots, test IDs, multiple assertions, and smell names as contextual signals, never automatic findings or acceptance gates.
- Do not edit production code unless the user explicitly requests it. Preserve unrelated code and owner state.
Sensitivity safety
Prove a test can fail, when safe, in this order:
- Run it against a known failing version or the pre-fix regression.
- Otherwise introduce one bounded temporary behavior break in a disposable copy or safe test seam, then fully revert it and verify restoration.
- Otherwise use mutation-tool evidence only when the repository already provides the tool.
- Otherwise state why direct sensitivity proof was unsafe or unavailable.
Never mutate owner work or production code merely to satisfy this check. Remove temporary state even when a command fails.
Activities and authority
| Activity | Contract |
|---|---|
| Plan | Produce risk/behavior coverage, test layer and path, fixtures/doubles, failure boundaries, commands and expected signals, plus justified gaps or alternate validation. |
| Write/improve | Make the smallest requested test changes, preserve unrelated code, and verify the claimed failure signal and passing behavior where safe. |
| Review | Stay read-only unless fixes are explicitly requested; assess actual protection, sensitivity, fidelity, determinism, and maintenance cost. |
These activities compose when requested. In embedded use, return test-engineering evidence only; the owning planning or review workflow retains authority over artifacts, findings, severity, matrices, reports, and verdicts. In standalone use, return the requested test plan or scoped review directly without adopting another workflow's schema.
Common workflow
- Fix the target, authority, requested activity, and output. Ask only if ambiguity changes the work.
- Inspect behavior and contracts, callers, nearby tests, framework/configuration/CI, repository commands, and installed versions relevant to the target.
- Before planning, writing, improving, or reviewing, read
references/test-quality-gates.mdfully. - Map material behaviors, boundaries, regressions, and risks to observable checks at the narrowest credible layer.
- Perform the requested activity; distinguish proven defects from signals and contextual heuristics.
- Prove sensitivity with the safe hierarchy above when practical.
- Run targeted checks, then affected repository checks. When flake risk warrants it, probe repetition, isolation, order dependence, and parallel execution without hiding failures behind retries.
- Report exact commands and results, sensitivity evidence, cleanup, skips, and confidence limits. If a check cannot run or cleanup/restoration is uncertain, stop and report the blocker rather than guessing.