Patch coverage
When you review a PR, one of the questions you're quietly asking is: if this change is wrong, will anything catch it? Patch coverage answers that question with a number: of the production code this PR adds, roughly what share is exercised by the tests in the same PR?
Note what it measures: the patch, not the project. Your repository's overall coverage percentage barely changes from one PR to the next and tells you nothing about today's change. Whether the fifty lines you're adding right now are tested — that's decision-relevant.
An estimate — and honestly labeled as one
Here's the deal we've made, openly: this number is an AI estimate, not a
measurement. Firetrail works out which lines your PR added to production
code and could actually run — blank lines, comments, a lone end, config
files, migrations and generated files don't count — then shows an AI every one
of those lines together with the PR's test files, and asks which lines the
tests reach. No instrumented test run happens.
Why build it this way? Measured coverage requires setup that many teams never finish: a CI integration, a coverage tool per language, report formats, paths. The estimate works on any language, any framework, with zero setup — and in exchange, it's approximate. So we treat it accordingly: the card is always badged "AI estimate", it shows its own confidence, and it never pretends to be measured execution. Use it as a strong hint about where the testing gaps are, not as a number to gate a merge on to two decimal places.
Every line, whatever the size
A small PR and a huge one get the same kind of number. The AI reads every added production line — a big PR is simply read in several passes and the results combined — so the estimate is never based on "the part that fit". If, for any reason, a full read isn't possible, the card says the estimate couldn't be made rather than showing a number it didn't earn.
Reading the card
On the PR analysis view, the coverage card shows:
- a ring with ~X% and the plain version: "X of Y executable added lines likely tested",
- a confidence badge — how sure the estimate is,
- a one-line summary of the PR's testing situation,
- files with gaps — expand to see each file's estimate, the specific line ranges that look untested, and for the covered parts which test reaches them ("tested by …"). This is the actionable part: a ready-made list of what a follow-up test should target, and a check that the tests you wrote land where you think they do,
- "Not counted" — code-looking files deliberately left out of the number
(
routes.rb,schema.rb, migrations, generated files), so a file you expected to see isn't a mystery.
Colors: green at 80%+ · amber 50–79% · red below 50%.
The no-tests warning
One case gets special treatment. When a PR changes production code and adds no tests at all, the card shows a prominent "⚠️ This PR has no test coverage" warning rather than a quiet 0%. Shipping untested behavior is the single most reliable generator of future debugging cost, so it's the one thing this feature refuses to whisper about. A low but nonzero estimate gets a softer "Low test coverage" caution.
Statuses you might see
- Estimated — the normal case; a percentage is shown.
- Nothing to estimate — the PR added no executable production code (docs, config, pure test changes).
- Off — patch coverage isn't switched on for your organization yet (see below).
- Couldn't be generated — the estimate itself failed, usually a brief AI service hiccup. Re-running the analysis retries it.
Switching it on
Patch coverage is included on Pro and Business plans, and it starts off: reading every added line of every PR with AI costs a little — a few cents per PR, a bit more for very large ones — so an organization owner decides. Turn it on under Organization settings → Patch coverage; the next analysis picks it up. See Plans & billing.