Coverage.py: Codeabdeckung für Python mit den Bordmitteln der Standardbibliothek

Messung statt Vermutung: was Coverage.py tut

Coverage.py misst Codeabdeckung, typischerweise während der Testausführung. Der beschriebene Mechanismus ist bewusst schlicht gehalten: Das Werkzeug nutzt die Codeanalysewerkzeuge und Tracing-Hooks, die die Python-Standardbibliothek bereitstellt, um festzustellen, welche Zeilen ausführbar sind und welche davon tatsächlich gelaufen sind. Damit bleibt die Messung nah am Interpreter, ohne eigene Instrumentierungssprachen oder externe Agenten. Die Projektbeschreibung auf GitHub setzt das Werkzeug mit dem bestimmten Artikel: the code coverage tool for Python. Die Metadaten weisen 3.406 Sterne, 519 Forks und 307 offene Issues aus; lizenziert ist der Code unter Apache-2.0, mit Hinweisen gebündelt in der NOTICE.txt. Dokumentation und Änderungshistorie liegen auf Read the Docs, das Repository und der Issue-Tracker auf GitHub.

Unterstützte Python-Versionen inklusive Free-Threading und PyPy3

Das README nennt die abgedeckten Interpretergenerationen präzise: Python 3.10 bis 3.15 rc1, eingeschlossen die free-threading-Variante, sowie PyPy3 in den Versionen 3.10 und 3.11. Die Erwähnung von Free-Threading ist beachtenswert, weil genau diese interpreternahen Änderungen Messwerkzeuge mit Tracing-Hooks typischerweise zuerst treffen; dass das Projekt sie ausdrücklich listet, zeigt, dass die Unterstüzung geprüft wurde. Die Versionen-Badges verweisen auf PyPI, wo das Paket unter dem Namen coverage erscheint. Für Teams, die mehrere Python-Linien parallel pflegen, heißt das: Eine einzige Coverage-Version deckt den Bereich von 3.10 bis zur 3.15-Vorschau ab, ohne dass pro Interpreter ein separates Werkzeug nötig wäre. Ältere Versionen nennt das README nicht; wer Details zu deren Status braucht, muss die Änderungshistorie auf Read the Docs aufschlagen.

Enterprise-Weg über die Tidelift-Subscription

Ein eigener README-Abschnitt richtet sich an Firmen. Coverage.py ist als Teil der Tidelift-Subscription erhältlich, die laut Beschreibung ein einziges Enterprise-Abo über alle eingesetzten Open-Source-Pakete legt und so die Flexibilität von Open Source mit dem Anspruch kommerzieller Software verbinden will. Das ist für Abteilungen relevant, die keinen ungesicherten Einsatz freiwilliger Projekte zulassen dürfen: Über Tidelift existiert ein vertraglicher Ansprechpartner, während das freie Projekt selbst keine Supportgarantie ausspricht. Wer diese Struktur nicht braucht, nutzt das Paket einfach über PyPI unter den Apache-2.0-Bedingungen. Das README trennt beide Wege sauber, ohne das freie Modell gegen das kommerzielle auszuspielen, und nennt die Absicherung als Angebot, nicht als Voraussetzung.

Sicherheitsmeldungen und der Python-Verhaltenskodex

Für den Meldeweg bei Sicherheitslücken gibt es eine klare Regel: Berichte laufen über den Tidelift-Sicherheitskontakt, der Koordination von Fix und Offenlegung übernimmt, statt öffentliche Issues zu verwenden. Damit folgt das Projekt dem heute üblichen Muster, Schwachstellen nicht über den normalen Tracker zu diskutieren. Die Community-Seite ist ebenfalls geregelt: Alle Beteiligten am Projekt werden gebeten, andere mit Respekt zu behandeln und die Vorgaben des Python Community Code of Conduct der PSF zu folgen; ein eigenes abweichendes Regelwerk führt das README nicht ein. Wer zum Code oder zur Dokumentation beitragen will, findet im Contributing-Abschnitt der Doku den Einstieg, auf den das README direkt verweist, inklusive des Hinweises für Bugmelder.

Metacov: das Werkzeug misst sich selbst

Ein Detail unterscheidet Coverage.py von vielen Nachahmern: Der Metacov-Badge verweist auf Abdeckungsberichte des Projekts selbst, veröffentlicht unter coveragepy.github.io/metacov-reports/latest.html. Das Testwerkzeug wird also mit seiner eigenen Technik gegen seine eigene Testsuite gemessen, und das Ergebnis ist öffentlich einsehbar. Für Bewerter ist das ein glaubwürdigeres Qualitätssignal als jede Sternezahl, weil es eine konkrete, reproduzierbare Aussage über die Testsuite macht. Dazu kommen Badges für den Teststatus und die Qualitätsprüfung der GitHub-Workflows testsuite.yml und quality.yml auf dem Zweig main. Wer die Pflege einschätzen will, kann diese drei Quellen nebeneinanderlegen und sieht, ob Messtiefe, Testsuite und Qualitätskontrolle tatsächlich zusammenpassen.

Pflegegrad und der Release-Rhythmus bis 7.16.0

Die Release-Historie zeigt kontinuierliche Arbeit: 7.16.0 erschien am 28. August 2026, gefolgt von 7.15.4 am 6. August und 7.15.3 am 2. August desselben Jahres, also mehrere Ausgaben innerhalb weniger Wochen. Der Standardzweig heißt main, und der README trägt einen Banner des Projekts Stand with Ukraine, was zur persönlichen Handschrift des langjährigen Betreuers Ned Batchelder passt, der unter dem Namen nedbat auf dem dezentralen Kurznachrichtendienst hachyderm.io erreichbar ist und über GitHub Sponsors unterstützt werden kann. Auch das Projekt selbst ist dort unter dem Account @coveragepy präsent. Für Planer bedeutet der Rhythmus: Der Code wird aktiv gepflegt, und Updates erscheinen in kurzen Abständen, was regelmäßige Aktualisierung in CI-Pipelines sinnvoll macht.

Fazit: der Referenzfall für Abdeckungsmessung in Python

Coverage.py ist der praktische Standard, wenn in Python-Projekten gemessen werden soll, welche Zeilen die Tests erreichen. Die Argumente sind im README greifbar: eine Messmethode, die auf Standardbibliothek statt Magie beruht, ein Versionsbereich von 3.10 bis 3.15 rc1 samt Free-Threading und PyPy3, öffentliche Metacov-Berichte, die das Werkzeug an sich selbst beweisen, und mit Tidelift ein Weg für Firmen, die vertragliche Absicherung verlangen. Grenzen hat die Beschreibung dort, wo das README schweigt: Benchmarks, Konfigurationsrezepte und Details zur Messung von Zweigabdeckung gehören in die Doku auf coverage.readthedocs.io, nicht in den Einstiegstext. Wer das Werkzeug einführt, startet mit dem Quick-Start-Abschnitt der Doku und prüft danach die own-Konfiguration gegen die Änderungshistorie der aktuellen Version 7.16.0.

Redaktionelles Fazit

Coverage.py ist die etablierte Wahl, um Testlücken in Python-Projekten sichtbar zu machen: Das Werkzeug nutzt Tracing-Hooks der Standardbibliothek, läuft laut README von Python 3.10 bis 3.15 rc1 inklusive Free-Threading sowie unter PyPy3 3.10 und 3.11, und die Dokumentation liegt auf coverage.readthedocs.io. Firmen mit Supportanspruch können das Paket über die Tidelift-Subscription beziehen; wer Sicherheitslücken meldet, wird ebenfalls über den Tidelift-Kontakt geleitet. Vor einem Upgrade lohnt der Blick auf die Release-Notizen von 7.16.0.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes