Seite 5 - PHPUnit

Wer HTTP-Clients nur mit echten API-Aufrufen testet, schreibt langsame, fragile Tests, die bei Netzwerkproblemen rot werden. Guzzles MockHandler, Response-Stacks und eigene HTTP-Adapter ermöglichen vollständige Kontrolle über alle Antwortszenarien – Erfolg, Timeout, Serverausfall und Retry-Kaskaden – direkt in PHPUnit, deterministisch und schnell.

Testbarkeit entsteht nicht beim Schreiben der Tests, sondern beim Entwurf der Klassen selbst. Wer Abhängigkeiten injiziert, Seiteneffekte isoliert und auf statische Aufrufe verzichtet, baut Code, der sich ohne Umwege testen lässt, ganz gleich welches Test-Framework am Ende zum Einsatz kommt. Dieser Artikel zeigt die Entwurfsprinzipien hinter testbarem PHP-Code jenseits von Assertions und Testrunnern.

PHPUnit 10 hat den jahrelang gewachsenen TestListener durch eine sauber typisierte Extension API ersetzt. Wer eigenes Logging, Slack-Benachrichtigungen bei Fehlschlägen oder projektspezifische Regeln in die Testsuite einbauen will, findet hier den Umstieg mit lauffähigen Beispielen.

Legacy Code ist Code ohne Tests – und er lässt sich ohne Tests nicht sicher ändern. Der Ausweg aus diesem Dilemma beginnt mit Characterization Tests: Tests, die das tatsächliche Verhalten dokumentieren, nicht das gewünschte. Seams einführen, statische Abhängigkeiten aufbrechen und schrittweise Klassen extrahieren – ohne eine einzige Zeile Produktionslogik zu ändern, bevor der erste Test grün ist.

Wer assertEquals schreibt, wo assertSame gemeint ist, schreibt Tests, die bestehen, obwohl die Software fehlerhaft ist. Assertions sind keine Boilerplate – sie sind die Sprache, in der ein Test beschreibt, was korrekt bedeutet. Die richtige Wahl zwischen Gleichheit, Identität, Typ und Struktur entscheidet darüber, ob ein Test ein Sicherheitsnetz ist oder falsche Sicherheit vermittelt.

Wer Tests ohne klare Muster schreibt, bekommt eine Testsuite, die langsam, brüchig und schwer zu verstehen ist. DataProvider, aussagekräftige Assertions, isolierte Mocks und eine sinnvolle Coverage-Strategie trennen Tests, die bei Refactoring sofort anschlagen, von grünen Tests, die trotz Bugs grün bleiben.

Die häufigste Fehlinvestition in der Testautomatisierung: zu viele langsame End-to-End-Tests und zu wenige schnelle Unit-Tests. Die Test-Pyramide gibt die richtige Gewichtung vor – drei Stufen mit klar getrennten Aufgaben, die zusammen eine zuverlässige Teststrategie ergeben.

Wer Magento-Module ohne Integrationstests entwickelt, merkt Regressionen erst im Staging oder in der Produktion. Das Magento Test Framework bietet eine vollständige Umgebung mit echter Datenbankisolation, automatischer Fixture-Verwaltung und dem gesamten Magento-DI-Container – vorausgesetzt, man richtet es korrekt ein.

Wer Magento-Code ohne Tests schreibt, merkt bei jedem Refactoring, wie fragil die Abhängigkeiten wirklich sind. PHPUnit-Tests für Repositories, Service-Contracts und ViewModels decken die Logik der wichtigsten Schichten ab – ohne den vollständigen Magento-Bootstrap zu benötigen

Beispielbasierte Tests prüfen nur die Fälle, die dem Entwickler eingefallen sind. Property-based Testing dreht den Ansatz um: statt konkreter Eingaben formuliert man Invarianten – Eigenschaften, die für jede denkbare Eingabe gelten müssen – und lässt die Bibliothek Tausende zufälliger Gegenbeispiele suchen.