otr-report ist ein Kommandozeilen Tool von Sebastian Bergmann, das aus den Open Test Reporting (OTR) XML Logs von PHPUnit lesbare HTML Reports erzeugt. PHPUnit schreibt diese Logs ab Version 13.2 über die Option --log-otr. Das Tool macht aus den maschinenlesbaren XML Daten genau die Auswertungen, die im Alltag zählen: welche Tests am langsamsten laufen, wie sich die Test Suite über viele CI Läufe entwickelt und wie ein einzelner Lauf im Detail ausgegangen ist.

OTR Logs sind präzise, aber für Menschen kaum lesbar. Sie protokollieren unter anderem Laufzeit, CPU Zeit und Speicherverbrauch pro Test sowie den Status jedes Testfalls. otr-report schließt diese Lücke zwischen Rohdaten und Erkenntnis: aus der XML Datei wird ein selbsterklärender Report, den Entwickler und Teams direkt im Browser auswerten können.

Das Tool ist Open Source unter BSD-3-Clause Lizenz und in der Version 1.0.1 vom 2. Juni 2026 verfügbar. Es ist bewusst auf die OTR XML Variante spezialisiert, die PHPUnit ab 13.2 schreibt und die zusätzliche PHP und PHPUnit spezifische Informationen enthält. Damit ist otr-report die natürliche Ergänzung zu PHPUnit für alle, die ihre Test Reports modernisieren wollen.

Bei Never Code Alone arbeiten wir täglich mit PHPUnit und richten Test Suites in produktiven PHP und Symfony Projekten ein. Test Reporting ist für uns kein Randthema, sondern Teil jeder sauberen PHP Beratung: Wer weiß, welche Tests bremsen und wie sich die Suite über die Zeit entwickelt, trifft bessere Entscheidungen über Architektur, CI Laufzeit und Refactoring Prioritäten. otr-report ist dafür das passende Werkzeug, und wir ordnen es für euer Projekt ein.

Konkret helfen wir beim Aufbau moderner Test Workflows: vom Umstieg auf das OTR Format über die Integration in eure CI CD Pipeline bis zur Parallelisierung großer Suites mit Paratest. Wenn ein Legacy Projekt erst auf PHPUnit 13.2 gehoben werden muss, übernehmen das unsere Spezialisten im PHP Update und beim PHP Refactoring, automatisiert mit Rector PHP und abgesichert durch statische Analyse mit PHPStan. So wird aus einem Reporting Tool ein echter Hebel für Code Qualität.

Jahrelang war JUnit XML das De facto Format für maschinenlesbare Test Reports. Das Problem: JUnit XML stammte ursprünglich gar nicht aus dem JUnit Projekt, sondern aus dem Ant Build Tool, und jedes Werkzeug interpretiert die Dateien etwas anders. Open Test Reporting (OTR) löst das. Das Format wurde vom JUnit Team als sprachunabhängiger und werkzeugunabhängiger Standard entworfen und protokolliert Tests als Event Stream XML.

PHPUnit hat OTR konsequent übernommen. Die Roadmap ist klar definiert und gibt die Richtung vor:

• PHPUnit 12.2 (Juni 2025): erste experimentelle Unterstützung für das OTR Format
• PHPUnit 13.1 (April 2026): OTR ist nicht mehr experimentell, JUnit XML wird deprecated
• PHPUnit 14 (Februar 2027, geplant): JUnit XML Erzeugung wird entfernt

Wer heute neue Pipelines aufsetzt, sollte direkt auf OTR setzen. Genau hier kommt otr-report ins Spiel: Es macht die OTR Logs nicht nur maschinen-, sondern menschenlesbar. Tools wie Codecov unterstützen OTR bereits, sodass der Umstieg ohne Bruch in bestehenden Pipelines möglich ist.

otr-report bündelt drei Auswertungen, die im Test Alltag immer wieder gebraucht werden. Jeder Befehl liest die OTR XML Datei und beantwortet eine konkrete Frage: Welche Tests bremsen? Wie entwickelt sich die Suite über die Zeit? Und wie ist ein einzelner Lauf im Detail ausgegangen?

Damit otr-report arbeiten kann, braucht es zunächst eine OTR XML Datei. PHPUnit schreibt sie mit der Option --log-otr. Die Datei protokolliert unter anderem, wie lange jeder Test gelaufen ist.

Der Befehl slowest liest diese Datei und gibt die zehn langsamsten Tests aus, sortiert von langsam nach schnell. Das ist der schnellste Weg, die Tests zu finden, die die Laufzeit der Suite dominieren. Mit --limit ändert ihr die Anzahl, mit --sort wechselt ihr zwischen Laufzeit, CPU Zeit und Speicher.

Besonders praktisch ist die Option --above-mean. Sie berechnet zuerst die mittlere Laufzeit aller Tests und listet dann nur die Tests, die langsamer als der Durchschnitt sind. Jeder Test bekommt einen Faktor, der zeigt, wie viele Male langsamer als der Mittelwert er ist. So trennt ihr echte Ausreißer von der breiten Masse.

Der Befehl trends liest alle OTR Logs in einem Verzeichnis und erzeugt einen einzigen HTML Report, der zeigt, wie sich eure Test Suite über mehrere Läufe entwickelt. Der Report enthält die Gesamtlaufzeit als Diagramm, die Anzahl der Tests als Diagramm, die zehn langsamsten Tests des jüngsten Laufs mit Sparkline und eine Tabelle aller Läufe. Ideal, wenn ihr pro CI Lauf ein OTR Log in ein gemeinsames Verzeichnis archiviert.

Der Befehl results erzeugt aus einem einzelnen Lauf einen in sich geschlossenen HTML Report, der das Ergebnis jedes Tests sichtbar macht. Er liefert eine Zusammenfassung des Laufs, eine Seitenleiste mit Baumstruktur nach Namespace, Klasse und Methode sowie pro Test den Status (SUCCESSFUL, FAILED, ERRORED, ABORTED oder SKIPPED), die Laufzeit und gemeldete Auffälligkeiten wie risky. Nicht bestandene Tests sind dabei standardmäßig aufgeklappt.

Mit der Option --testdox nutzt der Report die TestDox Informationen, also die lesbar aufbereiteten Klassen und Methodennamen, die PHPUnit im OTR Log mitschreibt. Fehlt diese Information bei einem Test, wird der ursprüngliche Name als Fallback verwendet.

otr-report wird als PHP Archive (PHAR) verteilt. Ihr könnt das PHAR direkt herunterladen oder, empfohlen, über Phive verwalten. Phive ist der saubere Weg, um Tool Abhängigkeiten eines Projekts zu pflegen, ohne sie mit den Laufzeit Abhängigkeiten im Composer zu vermischen.

Sebastian Bergmann rät ausdrücklich davon ab, dieses Tool über Composer zu installieren. Der Grund: Tools wie otr-report sind keine Laufzeit Abhängigkeiten eurer Anwendung. Wandern sie in die composer.json, können ihre eigenen Abhängigkeiten mit denen eures Projekts kollidieren. Phive hält Werkzeuge und Projekt sauber getrennt, ein Prinzip, das wir auch in unseren Beratungsprojekten konsequent empfehlen.

Der größte Mehrwert entsteht in der Pipeline. Wenn ihr bei jedem Lauf in eurer Qualitäts Pipeline ein OTR Log mit eindeutigem Namen in ein gemeinsames Verzeichnis schreibt, könnt ihr daraus jederzeit einen Trend Report bauen. So wird Test Performance messbar statt gefühlt: Ihr seht schwarz auf weiß, wenn die Suite langsamer wird oder einzelne Tests aus dem Ruder laufen.

In Kombination mit Paratest für parallele Ausführung und sauber getrennter Patch Coverage ergibt sich ein vollständiges Bild der Test Qualität. Wer GitHub Actions oder GitLab CI nutzt, archiviert die OTR Logs einfach als Build Artefakt und generiert den Report im Anschluss. Auch funktionale Tests und Integrationstests mit dem Symfony KernelTestCase landen so in einer einheitlichen Auswertung.

OTR ist bewusst breit angelegt. Die offizielle otr-report README bringt es auf den Punkt:

"Open Test Reporting is language-agnostic and tool-agnostic."

– otr-report README, sebastianbergmann/phpunit-otr-report, Juni 2026

Genau deshalb braucht es ein spezialisiertes Werkzeug: Das generische OTR Format kennt keine PHP Eigenheiten. otr-report ist hingegen auf die OTR XML Variante zugeschnitten, die PHPUnit ab 13.2 schreibt und die zusätzliche Informationen wie CPU Zeit, Speicherverbrauch und TestDox Namen enthält. Aus einem universellen Standard wird so ein Report, der für PHP Teams wirklich nützlich ist.

In Beratungsprojekten sehen wir regelmäßig Test Suites, die über Jahre gewachsen sind und deren Laufzeit niemand mehr im Blick hat. Genau hier setzt otr-report an: Statt zu raten, welcher Test die Pipeline ausbremst, liefert der slowest Befehl in Sekunden die Antwort. Häufig sind es wenige Ausreißer, die einen Großteil der Laufzeit verursachen, etwa weil sie ungewollt eine echte Datenbank oder externe Dienste ansprechen statt mit Test Doubles zu arbeiten.

Wir kombinieren die Auswertung gern mit Mutation Testing per Infection, um nicht nur schnelle, sondern auch aussagekräftige Tests sicherzustellen. Für die statische Absicherung setzen wir auf PHPStan und Psalm, für lokale Reproduzierbarkeit auf DDEV und Docker. Wenn ein Projekt erst auf PHPUnit 13.2 gehoben werden muss, läuft das über ein kontrolliertes PHP Update mit Rector PHP als Werkzeug. Wer tiefer in Test Reporting einsteigen will, findet im NCA PHP Glossar die passenden Bausteine von phpcov bis Patch Coverage.

Die wichtigsten Fragen zu otr-report, dem OTR Format und der Integration in PHPUnit und CI CD Pipelines 2026.