GitHub Code Coverage als Merge-Schutz: erst Rollout-Vertrag, dann Prozentzahl

Dev
GitHub kann Coverage- und Code-Quality-Schwellen als PR-Merge-Schutz nutzen. Teams sollten Baseline, Diff-Coverage, Ausnahmen und Flaky Tests vorher klären.
Ein Coverage Gate ist kein Qualitätszauber, sondern ein überprüfbarer Vertrag für riskante Änderungen.

Was passiert ist

GitHub hat am 30. Juni 2026 Merge Protection für Pull Requests über GitHub Code Coverage angekündigt. Repositories können Schwellen für Coverage oder Code Quality konfigurieren und einen Merge blockieren, wenn ein PR die Regel nicht erfüllt.

Warum es wichtig ist

Wichtig ist die Nähe zum Code Review. Coverage ist nicht mehr nur eine Metrik in einem externen Dashboard, sondern kann als required check in Rulesets oder Branch Protection auftauchen.

Community-Signal

Die Community diskutiert Coverage Gates seit Jahren kritisch: hohe Prozentwerte beweisen keine guten Tests, aber fallende Coverage erzeugt langfristige Testschulden. Beides ist wahr genug, um vorsichtig zu starten.

Operative Wirkung

Praktisch sollten Teams Total Coverage und Diff Coverage trennen. Die Gesamtzahl beschreibt langfristige Gesundheit; Diff Coverage zeigt, ob dieser PR ungetesteten Code hinzufügt.

Checkliste

Startet mit Soft Fail, speichert die aktuelle Main-Branch-Baseline, schließt generated files und Migrationen bewusst aus, und definiert, wer Coverage-Rückgänge genehmigen darf.

Risiken

Das Risiko liegt in falscher Sicherheit und langsamer CI. Ein Gate ersetzt keine guten Assertions, keine Integrationstests und keine Review-Verantwortung.

Rollout checklist

• Start with a baseline, not an ideal target.

• Separate total coverage from diff coverage.

• Document exclusions and exception approvers.

• Use soft fail before hard enforcement.

Quellen

다른 글