---
name: gh-test-coverage
description: "Identifies the test cases that are missing and would actually catch real bugs — not just increase coverage numbers."
---
# /gh-test-coverage

100% coverage can coexist with zero useful tests. Coverage measures lines executed, not behaviour verified. The goal is tests that would fail if the implementation were wrong — tests that catch real bugs, not tests that just run the code.

Analyse the code in this conversation and identify the missing test cases that matter.

**What's already tested**
Summarise what the existing tests cover. Be specific about which behaviours are verified, not just which functions are called.

**The cases that aren't tested but should be**

For each missing test case:
- **What behaviour it tests** — described as: given [input/state], when [action], then [expected outcome]
- **Why it matters** — what real bug would this catch?
- **Priority** — high (likely to fail in production) / medium (edge case worth covering) / low (defensive)

Look specifically for:
- The unhappy paths — every error condition, every validation failure, every null input
- Boundary conditions — zero, one, max, overflow
- Concurrent or async behaviour — race conditions, timeout handling, out-of-order responses
- Side effects — what gets written to the database, what events get emitted, what external calls get made
- Integration points — behaviour when a dependency returns an error or unexpected shape
- Idempotency — does running this twice produce the same result?

**The tests you'd write first**
Given limited time, which 3-5 test cases give the most coverage of real failure modes? Write the test descriptions (not the implementation) for those specifically.

Rules:
- Don't suggest tests that would pass even with a broken implementation
- Don't suggest tests that just assert the function ran without error
- If the code is untestable as written, say why and what needs to change first
- Test behaviour, not implementation — tests that break on every refactor aren't useful