Seite 8 - PHPUnit

Doctrine Repositories mit reinen Mocks zu testen prüft selten die eigentliche Query. Eine In-Memory-SQLite-Datenbank führt DQL und Query-Builder-Aufrufe echt aus, ganz ohne Datenbankserver, und macht Repository-Tests in Millisekunden statt Sekunden lauffähig.

Eine Kette aus mehreren assertEquals-Aufrufen, die einzelne Felder eines Domänenobjekts vergleichen, ist mühsam zu schreiben und liefert bei einem Fehlschlag nur bruchstückhafte Information. Eigene, domänenspezifische Assertions wie assertMoneyEquals oder assertValidOrderState bündeln diese Vergleiche an einer Stelle und liefern Fehlermeldungen, die sofort zeigen, was fachlich falsch war. Dieser Artikel zeigt, wie solche Assertions entstehen und wann sich der Aufwand lohnt.

Der native SoapClient von PHP und aehnliche proprietaere Legacy-Schnittstellen sind mit klassischen PHPUnit-Mocks nur schwer zu handhaben, weil sie Netzwerkverbindungen im Konstruktor aufbauen und final deklarierte Methoden mitbringen. Ein duennes Wrapper-Interface loest genau dieses Problem und macht ERP- oder Warenwirtschafts-Anbindungen in Magento-Projekten sauber testbar.

Wer PHPUnit-Ergebnisse nur als Terminalausgabe betrachtet, verschenkt den größten Teil des Mehrwerts automatisierter Tests. JUnit XML, HTML-Coverage, Teamcity-Output und strukturierte Testdauer-Reports machen Test-Ergebnisse für CI-Systeme, Teams und Monitoring auswertbar – über einen einzelnen Build-Lauf hinaus.

Eine einzelne projektweite Coverage-Zahl klingt beruhigend, kann aber genau die Kernmodule verstecken, die am dringendsten Tests braucht. Wer Coverage-Schwellenwerte pro Modul definiert und in der CI-Pipeline durchsetzt, schuetzt gezielt die Bereiche mit dem hoechsten Risiko, statt sich von einem guenstigen Durchschnitt taeuschen zu lassen.

PHPUnit 11 ist kein inkrementelles Update – es entfernt Docblock-Annotations zugunsten nativer PHP-Attribute, verschärft die Coverage-Konfiguration, ändert das Mock-System grundlegend und setzt PHP 8.1 als Mindestanforderung. Wer migriert, muss mehr als nur die Versionsnummer in composer.json ändern.

Zwei unabhängig deploybare PHP-Services, die sich über eine API verständigen, können jeweils für sich genommen eine grüne Testsuite haben und trotzdem inkompatibel werden. Contract Tests mit PHPUnit schließen genau diese Lücke zwischen Anbieter und Konsument.

Test-Driven Development wird oft entweder verteufelt oder als Allheilmittel angepriesen. Die Realität in PHP-Projekten ist differenzierter: TDD funktioniert hervorragend für bestimmte Problemklassen und erzeugt unnötigen Overhead für andere. Dieser Beitrag zeigt, wo der Unterschied liegt – mit Code, nicht mit Theorie.

@codeCoverageIgnore blendet Codezeilen aus der Coverage-Berechnung aus und ist damit ein legitimes Werkzeug fuer Faelle, in denen echte Testbarkeit weder sinnvoll noch moeglich ist, etwa bei trivialen Gettern oder unerreichbarem Defensive Code. Wird die Annotation aber grosszuegig ueber schwer testbaren, aber eigentlich testenswerten Code verteilt, verwandelt sich ein ehrliches Messinstrument in eine geschoente Zahl, die dem Team eine Sicherheit vorgaukelt, die nicht existiert.

Handgeschriebene Testdaten wie 'Testname' oder 'test@test.de' verschleiern echte Bugs, weil sie nie die Vielfalt echter Eingaben abbilden. Die Faker-Bibliothek erzeugt realistische Namen, Adressen und Preise, bleibt dabei mit festen Seeds aber vollständig reproduzierbar.