Evaluate Tests

"If tests break when you rename a private method, your tests are describing the solution, not the problem." — Adapted from Kent Beck

Two Modes

Pick the mode from the request. Run both for a full audit — Mode 1's findings feed the Behavioral and Coverage categories of Mode 2's scorecard.

Mode 1 — Test-File Quality

What This Skill Evaluates

For each test, assess two properties and one pattern:

1. Behavioral (does the test specify behavior?)

A behavioral test fails when the observable outcome breaks. An implementation-coupled test fails when internals change even if behavior is identical.

2. Structure-insensitive (does the test survive internal refactors?)

Run this mental test: if I renamed every private method and field in this class, would this test break? If yes, it is structure-coupled.

3. Horizontal slice pattern (were tests written without matching implementation?)

Signs in git history: a commit with 3+ test stubs followed by a commit with all implementations. Signs in test file: test methods that assert on code that clearly pre-existed the test (no trace of incremental growth in the test file).

Per-Test Classification

For each test, classify as one of:

Output Format

## Test Evaluation: [file or suite name]

### Summary
Tests evaluated: N | PASS: N | COUPLED: N | FRAGILE: N | THEATER: N

### Prioritized Rewrite List

| Priority | Test | Class | Reason | Suggested Fix |
|----------|------|-------|--------|---------------|
| 1 | `test_name` | COUPLED | Asserts `repo.save.called` — tests the how, not the what | Assert `repo.find(id) is not None` instead |
| 2 | `test_name` | FRAGILE | Reads `user._email` directly | Assert via `user.get_profile()["email"]` |
| 3 | `test_name` | THEATER | No assertion — only calls the method | Add assertion on return value or observable state |

### Horizontal Slice Signals
[commit evidence or "not detectable from test file alone — run Mode 2 (commit history)"]

Scope (Mode 1)

Pass a single file: evaluate all tests in it. Pass a directory: evaluate the most-changed test files first; ask before evaluating more than 20 tests in one turn.

For concrete rewrite examples by language: see Coupling Patterns.

Mode 2 — TDD Compliance (commit-history audit)

Verifies the discipline was followed, not just that tests exist. Tests written after implementation feel different, test different things, and provide different value than tests written first. This mode detects that from git history and scores it.

Workflow

1. Gather evidence — chronological git log, test + implementation file contents, coverage report (if available), test-run results.

2. Analyze commit order — did a failing-test commit precede each implementation commit? Flag commits containing both test and impl ("should be separate") and impl commits with no preceding test.

   Commit	Type	TDD compliant?
   abc123	Test	N/A (first)
   def456	Impl	Yes (test first)
   ghi789	Both	No (should be separate)
   jkl012	Impl	No (no preceding test)

3. Analyze test quality — run Mode 1's classification on the changed tests.
4. Check coverage quality — distinguish real coverage (tests fail when behavior breaks; edge and error paths covered) from theater (passes even with broken behavior; no assertions; happy path only).
5. Generate the scorecard.

AI Anti-Patterns to Detect

Compliance Scorecard

## TDD Compliance Scorecard: [repo/branch]
**Period**: [date range] | **Commits analyzed**: N

| Category | Score | Status |
|----------|-------|--------|
| Test-First Development | X/5 | GREEN/YELLOW/RED |
| Behavioral Testing | X/5 | GREEN/YELLOW/RED |
| Minimal Implementation | X/5 | GREEN/YELLOW/RED |
| Refactoring Discipline | X/5 | GREEN/YELLOW/RED |
| Coverage Quality | X/5 | GREEN/YELLOW/RED |
**Overall**: X/25 ([percentage]%)

Anti-patterns: [list or "none"]
Recommendations: Immediate: [...] | Short-term: [...] | Ongoing: [...]

Full scoring methodology: Compliance Scoring. AI-specific anti-pattern catalog: AI Anti-Patterns.

Discipline rules: evidence-based only — never claim compliance without commit-history proof; be constructive (findings drive improvement, not punishment); account for context (legacy code, time pressure, learning curves) before scoring.