Acceptance Testing

Acceptance Testing

Overview

Acceptance-driven backpressure connects specification acceptance criteria directly to test requirements, creating a validation chain that prevents premature completion claims. The system cannot cheat — you cannot claim a feature is done unless tests derived from spec acceptance criteria actually pass.

Announce at start: "I'm using the acceptance-testing skill to validate against specification criteria."

---

The Backpressure Chain

+------------+     derives      +------------+     validates    +------------+
|   SPECS    |---------------->|   TESTS    |---------------->|   CODE     |
|            |                  |            |                  |            |
| Acceptance |                  | Test cases |                  | Must pass  |
| Criteria   |                  | from AC    |                  | all tests  |
+------------+                  +------------+                  +------------+
      ^                                                              |
      |                    backpressure                               |
      +--------------------------------------------------------------+
      If tests fail, implementation must change (not the spec or test)

---

Phase 1: Extract Acceptance Criteria

Goal: From each specification file, extract all Given/When/Then acceptance criteria.

Actions

1. Locate all specification files (specs/*.md) 2. Extract every acceptance criterion with its ID 3. Document in structured format

Example Extraction

## From spec: 01-color-extraction.md

### AC-1: Extract dominant colors
- Given an uploaded image (PNG, JPG, or WebP)
- When color extraction is triggered
- Then 5-10 dominant colors are returned
- And each color includes hex, RGB, and HSL representations

### AC-2: Handle invalid images
- Given a corrupted or unsupported file
- When color extraction is attempted
- Then an appropriate error is returned
- And no partial results are produced

STOP — HARD-GATE: Do NOT proceed to Phase 2 until:

• [ ] All spec files are located and read
• [ ] Every acceptance criterion is extracted with an ID
• [ ] Criteria are in Given/When/Then format
• [ ] No criteria are ambiguous (if ambiguous, clarify with spec author)

---

Phase 2: Derive Test Cases

Goal: Map every acceptance criterion to at least one test case.

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: Every acceptance criterion must have at least one   │
│  corresponding test. No exceptions. If a criterion has no       │
│  test, the feature is NOT complete.                             │
└─────────────────────────────────────────────────────────────────┘

Traceability Table

Decision Table: Test Type for Acceptance Criteria

STOP — HARD-GATE: Do NOT proceed to Phase 3 until:

• [ ] Every acceptance criterion has at least one test mapped
• [ ] Test types are appropriate for the criterion type
• [ ] Test file locations are identified

---

Phase 3: Write Tests Before Implementation

Goal: Write acceptance tests that will fail until the feature is correctly implemented.

Actions

This phase integrates with test-driven-development:

1. Write test from acceptance criterion (RED) 2. Implement feature to pass test (GREEN) 3. Refactor while keeping test green (REFACTOR)

Behavioral Outcome Focus

STOP — HARD-GATE: Do NOT proceed to Phase 4 until:

• [ ] All acceptance tests are written
• [ ] Tests fail before implementation (RED confirmed)
• [ ] Tests verify behavioral outcomes, not implementation details

---

Phase 4: Validation Gates

Goal: Before claiming any task complete, ALL gates must pass.

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: ACCEPTANCE                                         │
│                                                                 │
│  Cannot claim completion without ALL acceptance tests passing.  │
│  If any acceptance test fails, the feature is NOT done.        │
│  Fix the implementation, not the spec or the test.             │
└─────────────────────────────────────────────────────────────────┘

STOP — HARD-GATE: Do NOT proceed to Phase 5 until:

• [ ] All validation gates pass
• [ ] Acceptance tests pass with green status
• [ ] No gates are skipped or marked as "will fix later"

---

Phase 5: Traceability Report

Goal: Produce a report linking every spec criterion to its test and result.

Report Template

## Acceptance Test Report

| Spec | Criterion | Test | Status |
|------|-----------|------|--------|
| 01-color-extraction.md | AC-1: Extract dominant colors | test/color.test.js:15 | PASS |
| 01-color-extraction.md | AC-2: Handle invalid images | test/color.test.js:42 | PASS |
| 02-palette-rendering.md | AC-1: Render palette grid | test/palette.test.js:8 | PASS |

### Summary
- Total criteria: N
- Tested: N
- Passing: N
- Failing: 0
- Coverage: 100%

---

Anti-Patterns / Common Mistakes

---

Rationalization Prevention

---

Integration Points

---

Skill Type

RIGID — The backpressure chain must not be bypassed. Every acceptance criterion must have a test. No completion without passing acceptance tests. Fix the implementation, not the spec or the test.