Jasper - Patterns

Test Reconciliation Patterns

This file documents effective patterns and approaches for test reconciliation work.

---

Pattern Template

## Pattern: {Pattern Name}

**When to use:** {Situations where this pattern applies}

**Approach:** {How to apply the pattern}

**Example:** {Concrete example from GE projects}

**Gotchas:** {Common pitfalls when applying this pattern}

**Related:** {Links to related patterns}

---

Core Patterns

Pattern: Three-Pass Reconciliation

When to use: When comparing TDD and POST test suites for the first time

Approach: 1. First pass: Identify obvious matches (same test name, same inputs) 2. Second pass: Identify semantic matches (different names, same behavior) 3. Third pass: Classify remaining divergences by type

Benefits: - Reduces false positives (tests that exist in both but named differently) - Ensures accurate divergence classification - Minimizes unnecessary routing to teams

Gotchas: - Don't assume test names match across TDD/POST (naming conventions differ) - Don't skip semantic analysis (POST tests may use different terminology)

---

Pattern: Specification-First Conflict Resolution

When to use: When TDD and POST tests conflict on expected outcomes

Approach: 1. Load formal specification (ground truth) 2. Compare both test expectations to specification 3. If spec is clear → identify incorrect test 4. If spec is ambiguous → escalate to Ron with context 5. Never arbitrate without checking specification first

Benefits: - Grounds conflict resolution in requirements (not implementation bias) - Identifies specification ambiguities early - Provides context for Ron's arbitration decisions

Gotchas: - Don't assume implementation is correct (specification is ground truth) - Don't skip specification check (intuition can be wrong)

---

Pattern: Implementation-Detail Whitelist

When to use: When classifying POST-only tests as acceptable implementation details

Approach: 1. Check if test validates WHAT (behavior) or HOW (implementation) 2. If HOW → check against whitelist: - Performance characteristics (response time, memory usage) - Error message formatting (specific text, not just error type) - Internal state validation (caches, queues, side effects) - Database query optimization - API call ordering (when order doesn't affect outcome) 3. If on whitelist → approve as Type 3 4. If uncertain → escalate for review

Benefits: - Consistent classification of implementation-detail tests - Reduces false positives (incorrectly routing to Antje) - Documents acceptable POST-only test categories

Gotchas: - Don't whitelist behavioral tests (if spec could define it, it's not impl-detail) - Don't expand whitelist without escalation (keeps standards consistent)

---

Patterns will be added as Jasper completes reconciliation work and Annegreet extracts learnings.