Seite 3 - PHPUnit

Parallele PHPUnit-Läufe sparen Zeit – aber sie stellen Anforderungen an Datenbankisolation, Fixture-Design und Konfiguration, die viele Teams erst nach dem ersten schmerzhaften Race Condition treffen. Dieser Artikel zeigt, wie paratest korrekt eingerichtet wird, warum Shared State die häufigste Fehlerquelle ist und wie man Test-Suites wirklich parallel-sicher macht.

Architekturregeln, die nur in Dokumenten existieren, werden gebrochen. Mit PHPUnit, PHP-Arch und der Reflection API lassen sich Schichtengrenzen, Modulabhängigkeiten und Designregeln als ausführbare Tests formulieren – die sofort anschlagen, wenn eine Klasse die falsche Schicht aufruft oder ein Modul eine verbotene Abhängigkeit einführt.

Code Coverage klingt nach einem einfachen Konzept, wird aber in großen Magento 2 Projekten schnell zur Bremse: Xdebug verlangsamt die Test-Suite um Faktor 5 bis 10, Reports sind riesig, und ohne Konfiguration misst man das Falsche. PCOV, gezielte Whitelist-Konfiguration und CI-Schwellenwerte machen Coverage zu einem nützlichen Werkzeug statt einem Engpass.

Wer Legacy-Code refactorn will, aber keine Tests hat, steht vor einem Henne-Ei-Problem: Tests schreiben erfordert Verständnis des Codes, Verständnis erfordert Lesen des Codes, aber Sicherheit beim Ändern erfordert Tests. Golden Master Tests lösen diesen Knoten – sie testen das Verhalten, bevor es verstanden wird.

In Magento 2 gibt es drei grundlegend verschiedene Test-Typen mit sehr unterschiedlichen Laufzeiten, Wartungskosten und Einsatzbereichen. PHPUnit für Unit- und Integrationstests, MFTF für End-to-End-Browser-Tests und REST-API-Tests für die Webservice-Schicht. Die häufigsten Fehler in Magento-Test-Strategien: zu viele MFTF-Tests, zu wenige Unit Tests, und API-Tests, die eigentlich Logik-Tests sein sollten.

Tests direkt in der IDE mit einem Klick oder Tastenkürzel auszuführen, ohne die Konsole zu öffnen, ist ein Produktivitätsgewinn, der schnell zur selbstverständlichen Arbeitsweise wird. PhpStorm unterstützt PHPUnit für Docker-basierte Magento-Setups vollständig – wenn der Remote-Interpreter und die Run Configuration korrekt konfiguriert sind. Dieser Artikel führt durch den vollständigen Setup-Prozess.

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.

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.