Startklar mit PHPUnit

Worum es geht

Der erste Test ist schnell geschrieben, oder vom Agenten erzeugt. Damit er im Alltag etwas nützt, braucht dein Projekt mehr: einen Platz für Tests, eine Ordnung, die auch bei tausend Tests noch trägt, und einen Testlauf, der auf jedem Rechner dasselbe Ergebnis liefert. Vor allem braucht es einen Testlauf, der automatisch passiert, bevor eine Änderung in den Hauptzweig kommt.

In dieser Schulung bringst du PHPUnit in dein Projekt. Es geht nicht darum, wie du Tests schreibst, sondern darum, was dein Projekt braucht, damit Tests zum Alltag werden. Du legst fest, wo welche Tests liegen und wie du auswählst, was läuft. Du lässt deine Tests im Container laufen, mit derselben PHP-Version wie in Produktion, und in der CI, wo ein roter Test den Merge verhindert.

Die letzte Sitzung gehört den Daten. Tests gegen die Produktivdatenbank sind verlockend und gefährlich: Sie können Daten löschen, E-Mails an echte Kundinnen und Kunden schicken und personenbezogene Daten dorthin bringen, wo sie nichts zu suchen haben. Du richtest eine Testdatenbank mit synthetischen Daten ein und sorgst technisch dafür, dass kein Test die Produktion erreicht.

So arbeitest du in dieser Schulung

Du arbeitest an allem, was um die Tests herum nötig ist, schreibst aber selbst keine Tests. Die sind schon da: im Übungsprojekt als vorbereitete Sammlung, in deinem eigenen Projekt von einem Agenten erzeugt oder aus dem Übungsprojekt übernommen.

Wenn du ein eigenes Projekt mitbringst und daran arbeiten darfst, arbeitest du daran, sonst am Übungsprojekt. Das ist eine kleine, gewachsene PHP-Anwendung ohne Tests, mit Datenbank und E-Mail-Versand, und an ihr laufen alle Vorführungen. Dazu gehören ein Containerfile mit PHP 8.5, Composer und den Erweiterungen der Anwendung, eine Compose-Datei mit Datenbank und Mailcatcher und Vorlagen für GitHub Actions und GitLab CI.

Jede Entscheidung wird begründet, damit am Ende keine Vorlage zum Kopieren steht, sondern ein Projekt, dessen Einrichtung dein Team versteht.

Ablauf

1. 1

   Sitzung 1: PHPUnit ins Projekt holen

   Was braucht dein Projekt, damit der erste Test läuft?

   • Installation mit Composer als Entwicklungsabhängigkeit, das PHAR als Alternative, und autoload-dev für den Testcode
   • Welche PHPUnit-Version zu welcher PHP-Version passt, und wie lange sie unterstützt wird
   • phpunit.xml mit --generate-configuration erzeugen, Zeile für Zeile erklären und gemeinsam ausdünnen, mit einer Begründung für jede Streichung, auch die von warnWhenPhpIsNotConfiguredForDevelopment
   • PHP für die Entwicklung konfigurieren: Fehlerberichte und Zusicherungen
   • Der erste Lauf mit vorbereiteten Tests: --testdox, --filter, IDE-Integration, und wie du Erfolg, Fehlschlag, Fehler, Warnungen und Hinweise liest

   Ergebnis: PHPUnit, das in deinem Projekt oder im Übungsprojekt läuft, mit einer Konfiguration, in der jede verbleibende Zeile eine Begründung hat

2. 2

   Sitzung 2: Ordnung in der Testsuite

   Wo liegt welcher Test, und wie wählst du aus, was läuft?

   • Verzeichnisse nach Testgröße getrennt (tests/unit, tests/integration, tests/end-to-end) oder entlang von src/, und was daraus folgt
   • Namensräume und autoload-dev, Namenskonventionen für Testklassen und Testmethoden
   • Testsuites und Gruppen in der phpunit.xml, die Auswahl mit --testsuite und --group, und mit <source> festlegen, was zum Produktivcode gehört
   • Wohin gemeinsamer Testcode gehört: Hilfsklassen, Fakes, Builder
   • Ein Einstiegspunkt für alle Läufe: Composer-Skripte wie composer test und composer test:unit

   Ergebnis: Die unsortierte Testsammlung des Übungsprojekts in einer festgelegten Struktur, mit Testsuites, Konventionen und Composer-Skripten als Einstiegspunkt für jeden Lauf

3. 3

   Sitzung 3: Wann und wo Tests laufen

   Läuft deine Testsuite überall gleich, und wer merkt, wenn sie rot ist?

   • Wo: auf dem Host, im Container, in der CI, und warum die PHP-Version und die Erweiterungen denen der Produktion entsprechen sollten
   • Container für Tests: Containerfile, Code einbinden, Composer-Cache, Docker und Podman
   • Wann: beim Entwickeln in der IDE, vor dem Commit (Git-Hooks als Option, nicht als Sicherheitsnetz), in der CI bei jedem Push und vor dem Merge
   • Der Exit-Code als Urteil: warum die CI nicht die Ausgabe liest
   • CI-Konfiguration für GitHub Actions und GitLab CI, mit der ein Merge erst nach einem grünen Lauf möglich ist
   • Ausblick: was wann laufen sollte, wenn die Suite wächst

   Ergebnis: Ein Testlauf im Container mit derselben PHP-Version wie in Produktion und in der CI bei jedem Push, und ein absichtlich eingecheckter roter Test, an dem du siehst, dass der Merge gesperrt ist

4. 4

   Sitzung 4: Tests und Daten

   Warum hat die Produktivdatenbank in deinen Tests nichts verloren?

   • Datenverlust: Tests legen Daten an, ändern und löschen sie, Fixtures überschreiben Bestände, Aufräumen leert Tabellen
   • Seiteneffekte: E-Mails an echte Kundinnen und Kunden, Aufrufe echter Zahlungsdienste
   • DSGVO: warum personenbezogene Daten in Test- und Entwicklungsumgebungen ein Problem sind, und warum eine „anonymisierte“ Kopie oft nur pseudonymisiert ist
   • Nicht reproduzierbar: Ein Test, der von wechselnden echten Daten abhängt, ist heute grün und morgen rot
   • Die Alternative: eine eigene Testdatenbank im Container, das Schema aus den Migrationen, synthetische Testdaten aus Fixtures und Buildern und ein frischer Stand für jeden Lauf
   • Technische Sperren: getrennte Zugangsdaten, eigene Umgebungsvariablen für Tests, ein Bootstrap, der abbricht, wenn die Verbindung zur Produktion zeigt, und ein Mailcatcher statt echtem Versand

   Ergebnis: Eine Testdatenbank im Container mit synthetischen Daten und ein Bootstrap, der einen Lauf mit den Zugangsdaten der „Produktivdatenbank“ des Übungsprojekts abbricht, bevor ein einziger Test ausgeführt wird

Für wen

• PHP-Teams, die mit automatisierten Tests beginnen wollen
• Entwicklerinnen und Entwickler, deren Tests nur auf einem Rechner grün sind oder in der CI gar nicht laufen
• Tech Leads, die für ihr Team die Grundlage für automatisierte Tests schaffen

Voraussetzungen

• Erfahrung mit PHP und Composer
• Idealerweise ein eigenes Projekt, an dem du in der Schulung arbeiten darfst, sonst arbeitest du am Übungsprojekt
• Für die Übungen: PHP 8.5, Composer, Git, Docker oder Podman und ein Konto bei GitHub oder GitLab
• Vorwissen im Testen ist nicht nötig: Die Begriffe vermittelt „Testen verstehen“, das du parallel besuchen kannst

Das nimmst du mit

• Du bringst in deinem Projekt Tests zum Laufen und weißt, warum sie so eingerichtet sind
• Du gibst deinen Tests eine Ordnung und wählst gezielt aus, welche laufen
• Du lässt deine Tests auf jedem Rechner, im Container und in der CI mit demselben Ergebnis laufen
• Du sorgst dafür, dass ein roter Test eine Änderung aus dem Hauptzweig heraushält
• Du testest mit synthetischen Daten und sperrst deine Tests technisch von der Produktion aus

Verwandte Schulungen

Diese Schulung ist Teil des Lernpfads Einstieg ins Testen.