Files
ECC/skills/test-collaboration/templates/TESTS.example.md
T
haelyra 412347a2ab feat(skills): integrate optional test governance workflows from PR 3413
Preserve complete contributor head. Keep current-session invocation, project-defined verification gates and existing task authorization; no new commands or completion authority. Disposable Claude/Codex install and removal verified.
2026-10-11 02:02:49 -04:00

109 lines
5.0 KiB
Markdown

# TESTS.md — Test Assets and Required Test Points
> This registry answers: What tests exist? Which rules require protection? Where is the evidence?
> Aggregate assets by module or workflow rather than mirroring every test function. Test code is executable truth; this document stores only indexes, assessments, and evidence.
## 1. Test Entry Points
| Execution group | Command | When to run | External dependencies |
|---|---|---|---|
| Default tests | `TODO` | Before each commit / CI | None or unverified |
| Contract validation | `TODO` | Contract changes / CI | Contract tooling |
| Consumer contract tests | `TODO` | Client or consumer changes | `TODO` |
| Provider contract tests | `TODO` | Server or provider changes | `TODO` |
| Specialized E2E | `TODO` | Critical path or pre-release | `TODO` |
## 2. Test Asset Map
Controlled levels: `unit`, `integration`, `contract`, `E2E`, `smoke`.
Controlled purposes: `rule protection`, `critical path`, `regression protection`, `specialized protection`. Separate multiple purposes with commas.
| Module or workflow | Level | Purpose | Execution group | External dependencies | Test location | Assessment |
|---|---|---|---|---|---|---|
| Example: order total calculation | unit, integration | rule protection | default tests | none | `tests/order/` | required |
| Example: successful payment path | E2E | critical path | specialized E2E | payment sandbox | `tests/e2e/payment/` | missing |
Assessment values: `required`, `missing`, `possibly duplicate`, `possibly stale`. The last two require human confirmation and do not authorize deletion.
## 3. Cross-Boundary Contract Evidence
Use only when clients and providers develop independently. Reference the single contract source; do not duplicate field definitions here.
| Interface or message boundary | Single contract source | Contract validation | Consumer evidence | Provider evidence | Integration evidence | Assessment |
|---|---|---|---|---|---|---|
| Example: order detail API | `TODO: OpenAPI / JSON Schema / GraphQL / protobuf path` | command + exit code | generated type/mock + test command | serialized-response validation command | minimum E2E command | missing |
Assessment values: `missing`, `covered`, `not applicable`, `unverifiable`. Separate green consumer and provider tests remain `missing` or `unverifiable` unless both reference the same contract.
## 4. Required Test Points
State values: `missing`, `in progress`, `unverified`, `covered`, `not applicable`.
### TEST-ORDER-001 — Order Amount Rule
- State: missing
- Purpose: rule protection
- Source: requirement / business rule / risk / bug identifier
- Representative input: the minimum realistic input that triggers the rule
- Observable expectation: a result that can be asserted without copying the source criteria
- Level: unit
- Execution group: default tests
- Boundary: amount calculation runs for real; no external system
- Test file: TODO
- Test node: TODO
- Command: TODO
- Evidence: TODO
### TEST-BUG-001 — Defect Regression Protection
- State: missing
- Purpose: regression protection
- Source: BUG-001
- Real failure shape: original input, path, and boundary condition that caused the defect
- Observable expectation: behavior that must remain true after the fix
- Level: integration
- Execution group: default tests
- Boundary: core logic runs for real; external services use the project's existing fake
- Test file: TODO
- Test node: TODO
- Command: TODO
- Before-fix evidence: TODO
- After-fix evidence: TODO
### TEST-API-001 — Cross-Boundary Interface Contract
- State: missing
- Purpose: rule protection, critical path
- Source: interface requirement / contract change / field-drift bug
- Single contract source: path plus version, commit, or hash
- Observable expectation: consumer and provider obey the same field names, types, nullability, enums, and error shape
- Level: contract, E2E
- Consumer command and evidence: TODO
- Provider command and evidence: TODO; must validate the actual serialized boundary
- Integration command and evidence: TODO
- Unverified boundaries: TODO
## 5. Manual Verification Exits
Use only when automation is genuinely unavailable. “Hard to test” is not a reason.
| Source | Why automation is unavailable | Manual steps | Passing evidence | Owner |
|---|---|---|---|---|
| TODO | TODO | TODO | TODO | TODO |
## 6. Current Gaps and Actions
| Priority | TEST-ID or asset | Gap | Next action | State |
|---|---|---|---|---|
| P0 | TODO | TODO | TODO | missing |
## 7. Maintenance Triggers
- Test directories, configuration, CI, or standard entry points change: rescan the affected area.
- A requirement, business rule, risk, or bug is added: create or link a TEST-ID.
- A major feature, interface, or security boundary changes: rescan the affected critical path.
- A cross-boundary contract changes: revalidate the contract, regenerate consumer assets, and rerun consumer, provider, and integration tests.
- Before stage delivery: reconcile TEST-IDs and evidence touched by the change.
- Rescan the entire test system only after a testing-system rebuild or when the map is clearly stale.