PHPUnit 12: Sebastian Bergmann über Release, Änderungen und Highlights

Version 12 des PHP-Testing-Frameworks PHPUnit soll Anfang Februar 2025 erscheinen. iX spricht mit Sebastian Bergmann, Initiator, Hauptentwickler und Maintainer des Projekts, über den aktuellen Entwicklungsstand, anstehende Änderungen und persönliche Highlights des kommenden Releases.

Sebastian Bergmann ist Open-Source-Mensch der ersten Stunde. Seine Erfahrungen gibt er in Publikationen und auf Konferenzen weiter. Darüber hinaus ist er Mitgründer und Principal Consultant von The PHP Consulting Company (thePHP.cc).

iX: PHPUnit 12 wird voraussichtlich im Februar 2025 erscheinen: Wie ist der aktuelle Entwicklungsstand?

Sebastian Bergmann: Eine neue Hauptversion wie PHPUnit 12 wird jedes Jahr am ersten Freitag im Februar veröffentlicht. Die Veröffentlichung von PHPUnit 12.0 ist also für den 7. Februar 2025 geplant.

Ein Release wie PHPUnit 12.0 dient hauptsächlich zum Aufräumen und bietet eine jährliche Gelegenheit, Änderungen vorzunehmen, die nicht abwärtskompatibel sind. Zum Beispiel werden Features entfernt, die in einer früheren Version als "deprecated" markiert wurden.

Im Main-Branch des PHPUnit-Repositorys auf GitHub sind bereits alle geplanten Änderungen implementiert, die nicht abwärtskompatibel sind. Der aktuelle Entwicklungsstand entspricht in diesem Punkt also schon dem, was bei der Veröffentlichung von PHPUnit 12 zu erwarten ist.

Persönliche Highlights

iX: Welche Features der neuen Version sind deine persönlichen Highlights?

Sebastian Bergmann: Eine neue Version wie PHPUnit 12.0 bringt meist nicht viele neue Features mit, da sie im Februar die Grundlage für die Feature-Releases des Jahres bildet. Ein paar kleine neue Features gibt es in PHPUnit 12.0 aber doch, um die Code Coverage noch besser über Attribute kontrollieren zu können.

Mein persönliches Highlight von PHPUnit 12 ist allerdings kein neues Feature, sondern vielmehr das Ergebnis von Aufräum-, Umbau- und Verbesserungsarbeiten der letzten Jahre: endlich sind Test Stubs von Mock Objects klar getrennt.

Kurzer Exkurs: In der objektorientierten Programmierung gibt es verschiedene Arten von Objekten: Services, Entities und Wertobjekte zum Beispiel. Services kapseln Prozesse, das können Geschäftsprozesse sein oder eher technische Dinge wie das Laden und Speichern von Daten. Services implementieren im Idealfall eine Schnittstelle (Interface).

Beim Testen verwenden wir eine echte Implementierung dieser Schnittstelle, wenn wir diese Implementierung testen wollen. Wir verwenden einen Test Stub dieser Schnittstelle, wenn wir eine Komponente testen wollen, die von dem Interface abhängt. Wir verwenden ein Mock Object des Interfaces, wenn wir die Kommunikation zwischen kooperierenden Objekten testen wollen.

Als Test Doubles vor circa 20 Jahren in die damaligen Testframeworks eingeführt und später populär wurden, waren die Begriffe Test Stub und Mock Object noch austauschbar. Aus diesem Grund bot PHPUnit zunächst nur eine API, die Methode getMock(), zur Erzeugung von Test Doubles an. Das war verwirrend und der Grund, warum wir in den letzten Jahren viel an den APIs für Test Doubles gearbeitet haben.

Beim Lesen von Testcode ist es wichtig zu verstehen, was er tut und warum er es tut. Wenn beispielsweise eine Abhängigkeit zu Testzwecken durch ein Test Double ersetzt wird, ist es wichtig zu wissen, warum dies geschieht. Wenn die zu testende Komponente nur von einer Abhängigkeit isoliert werden soll, sollte ein Test Stub verwendet werden. Wenn die Kommunikation zwischen Objekten spezifiziert und/oder verifiziert werden soll, istwird ein Mock Object benötigt. Wird nun im Testcode immer und überall eine API zur Erzeugung von Mock Objects verwendet, so ist immer erst auf den zweiten oder dritten Blick erkennbar, worum es im Test geht. Durch die strikte Trennung der APIs für die Erzeugung von Test Stubs und Mock Objects wird dies nun klarer.

iX: Wie können sich Entwicklerinnen und Entwickler auf PHPUnit 12 vorbereiten?

Sebastian Bergmann: Da die Änderungen, die nicht abwärtskompatibel zu PHPUnit 11 sind, bereits implementiert sind (siehe oben), kann, wer mutig ist, die eigenen Tests schon mit dem, was PHPUnit 12 werden wird, testen.

Einfacher und weniger riskant geht es natürlich mit der aktuellen stabilen Version: Wenn ich meine Tests mit PHPUnit 11.5 ausführen kann, ohne dass der Test Runner "meckert", dass ich abgekündigte Funktionalität (Deprecations) verwende, dann weiß ich, dass ich meine Tests mit PHPUnit 12 ausführen kann.

Die Fragen stellte Madeleine Domogalla.

(mdo)