Seite 7 - PHPUnit

Der automatische Property-für-Property-Vergleich von assertEquals() scheitert bei Wertobjekten mit eigener fachlicher Gleichheitsdefinition. assertObjectEquals() und eigene Comparator-Klassen lösen dieses Problem, indem sie die tatsächliche Vergleichslogik der Klasse selbst nutzen.

PHPUnit markiert Tests nicht nur als bestanden oder fehlgeschlagen, sondern gelegentlich auch als risky. Das ist kein kosmetisches Detail, sondern ein Hinweis auf Tests, die zwar gruen sind, aber nichts aussagen oder sich schlecht verhalten: keine Assertion, unerwarteter Output oder heimliche Aenderungen am globalen Zustand. Wer diese Warnungen ignoriert, sammelt sich einen Testbestand an, der Vertrauen vortaeuscht, das er nicht verdient.

Ein neues Attribut oder ein geaendertes Attribut-Set kann unbemerkt bestehende Produktdaten oder Frontend-Logik brechen. Wer Attribut-Setup-Skripte und die davon abhaengige Logik testet, findet solche Regressionen vor dem Deployment statt danach.

Magento-GraphQL-Resolver implementieren ein einfaches, gut definiertes Interface, das sich direkt und ohne den Aufbau des kompletten Schemas per PHPUnit testen laesst, sobald man Feldaufloesung von Datenbeschaffung sauber trennt.

Wer in Unit-Tests wahllos alles mockt, was mit einer Klasse zusammenhängt, baut Tests, die bei jedem Refactoring brechen, ohne dass sich am Verhalten der Anwendung etwas geändert hat. Die Taxonomie nach Gerard Meszaros unterscheidet Dummy, Stub, Fake, Spy und Mock als fünf klar abgegrenzte Rollen mit unterschiedlichem Zweck, unterschiedlicher Prüflogik und unterschiedlichem Kopplungsgrad an Implementierungsdetails. Dieser Beitrag zeigt die Theorie hinter jedem Test Double anhand handgeschriebener PHP-Implementierungen, unabhängig von einem bestimmten Test-Framework.

Tests, die von der aktuellen Uhrzeit, zufällig generierten UUIDs oder Pseudozufallswerten abhängen, sind flaky: Sie schlagen manchmal fehl, manchmal nicht, und die Ursache ist schwer zu reproduzieren. Clock-Interfaces, UUID-Factories und kontrollierter Zufall lösen dieses Problem grundlegend – ohne den Produktionscode zu komplizieren.

Wer für jede Eingabevariante eine eigene Testmethode schreibt, vervielfacht Wartungsaufwand statt Testabdeckung. Der Data Provider von PHPUnit trennt Testlogik von Testdaten und macht aus zehn fast identischen Methoden eine einzige, klar lesbare Testmethode mit einem Dutzend Datensätzen.

Ein Test, der manchmal besteht und manchmal nicht, ist schlimmer als gar kein Test. Er untergräbt das Vertrauen in die gesamte Testsuite, erzwingt manuelle Re-Runs und versteckt echte Regressionen hinter rauschen. Flaky Tests entstehen aus spezifischen Ursachen – und alle lassen sich dauerhaft beheben.

Sicherheitsluecken in Produktionsabhaengigkeiten werden meist ernst genommen, waehrend Test- und Dev-Abhaengigkeiten wie PHPUnit-Plugins oder Coverage-Werkzeuge oft unbeachtet bleiben. Dabei laufen genau diese Pakete mit vollen Rechten in der CI/CD-Pipeline und sind ein reales Einfallstor fuer Supply-Chain-Angriffe, das composer audit gezielt aufdecken kann.

Ein Test, der prüft, ob eine Nachricht auf einem Bus gelandet ist, sagt nichts darüber aus, ob der zugehörige Handler das Richtige tut. Mit InMemoryTransport und TraceableMessageBus lassen sich Symfony Messenger Handler synchron, deterministisch und ohne RabbitMQ oder Redis in der Pipeline testen.