Tests mit System

Worum es geht

Tests entstehen heute schneller als je zuvor. Ein Coding Agent schreibt sie in Sekunden, in jedem erdenklichen Stil. Ohne Vorgaben wächst eine Suite, in der jeder Test anders aussieht, in der niemand weiß, welche Tests es überhaupt geben sollte, und die beim nächsten Refactoring an den falschen Stellen zerbricht.

Damit du als Mensch am Steuer bleibst, braucht dein Projekt eine Testarchitektur: eine Entscheidung, welche Erwartungen auf welcher Ebene geprüft werden, und Regeln, wie ein Test aussieht. Regeln allein reichen aber nicht, wenn niemand ihre Gründe kennt. Und Regeln, die nur in einem Dokument stehen, werden nicht eingehalten, weder von Menschen noch von Agenten.

In dieser Schulung legst du die Testarchitektur für ein Projekt fest und begründest jede Entscheidung. Anschließend machst du deine Regeln prüfbar: mit einer strengen Konfiguration von PHPUnit und mit PHPStan, das auch deinen Testcode analysiert und dank seiner PHPUnit-Erweiterung versteht, was ein Test tut.

Erst entscheiden, dann durchsetzen

Die erste Sitzung trifft die Entscheidungen und begründet sie, die zweite macht sie prüfbar. Jede Regel bekommt eine Begründung und einen Vermerk, ob ein Werkzeug sie prüfen kann oder ob sie ins Review gehört.

Ausgangspunkt beider Sitzungen ist die grüne Testsuite eines Übungsprojekts mit den Schichten Domäne, Anwendung und Adapter. Teils haben Menschen sie geschrieben, teils ein Agent, und gemeinsamen Regeln folgt sie nicht.

Ablauf

1. 1

   Sitzung 1: Die Testarchitektur festlegen

   Welche Tests braucht dein Projekt, und wie sollen sie aussehen?

   • Am Steuer bleiben: Ein Agent schreibt Tests in jedem Stil, und ohne Vorgaben bestimmt er, wie deine Suite aussieht
   • Die Testpyramide mit Ebenen, Verteilung und Kosten, Alternativen wie Testing Trophy und Testing Honeycomb, und wann welche passt
   • Testebenen und Architektur: Domänenlogik in kleinen Unit Tests, Adapter in Integrationstests, wenige End-to-End-Tests für die wichtigsten Abläufe
   • Testsuites und Verzeichnisse als Ausdruck der Teststrategie
   • Regeln für Testcode, jede mit ihrem Grund: Testnamen als Sätze über Verhalten, ein Verhalten pro Test nach Arrange, Act, Assert, keine Schleifen und Bedingungen im Test, assertSame() statt assertEquals() oder assertTrue($a === $b), die Angabe, welchen Code ein Test abdeckt
   • Regeln für Test Doubles und Testdaten: Stub für Eingaben, Mock nur für geprüfte Kommunikation, keine Test Doubles für Wertobjekte, nur eigene Schnittstellen ersetzen, Fixtures im Test statt Mystery Guest, Data Provider mit benannten Datensätzen
   • Lesbar und wartbar: Ein Test wird gelesen, wenn er rot ist

   Ergebnis: Eine Teststrategie für das Übungsprojekt, die festlegt, welche Erwartungen auf welcher Ebene geprüft werden, und eine Testrichtlinie von einer Seite, in der jede Regel eine Begründung und einen Vermerk hat, ob ein Werkzeug sie prüfen kann

2. 2

   Sitzung 2: Vorgaben durchsetzen

   Wie sorgst du dafür, dass sich jeder Test an die Vorgaben hält, auch ein generierter?

   • PHPUnit-Konfiguration als Vorgabe: riskante Tests, Warnungen und Deprecations scheitern lassen (failOnRisky, failOnWarning), zufällige Reihenfolge, keine Ausgabe in Tests, die Angabe des abgedeckten Codes (requireCoverageMetadata) und versiegelte Mock-Objekte (requireSealedMockObjects) verlangen
   • Testcode ist Code: PHPStan auf demselben Level wie für den Produktivcode
   • Die PHPUnit-Erweiterung für PHPStan versteht Zusicherungen und Mock-Objekte und meldet etwa Mocks für nicht existierende Methoden, falsch verwiesene Data Provider und Zusicherungen, für die es eine passendere gibt
   • PHP-CS-Fixer mit seinen PHPUnit-Regeln für einheitliche Schreibweisen
   • Eine eigene PHPStan-Regel für eine Konvention der Testrichtlinie, etwa „keine Test Doubles für Wertobjekte“
   • Was kein Werkzeug prüft: Orakel, fachliche Richtigkeit, sinnvolle Testfälle, und eine Checkliste für das Review
   • Die Testrichtlinie als Vorgabe für Coding Agents: kurz im Kontext, der Rest in Werkzeugen

   Ergebnis: Eine strenge phpunit.xml und PHPStan mit der PHPUnit-Erweiterung, die jeden Test zurückweisen, der gegen die prüfbaren Regeln deiner Testrichtlinie verstößt, auch einen generierten, und eine Richtlinie für Mensch und Agent

Für wen

• Tech Leads, Softwarearchitektinnen und -architekten, die Vorgaben für die Tests ihres Teams festlegen
• Erfahrene Entwicklerinnen und Entwickler, die in ihrem Team für Testqualität sorgen
• Teams, die Tests von Coding Agents schreiben lassen und dabei die Kontrolle behalten wollen

Voraussetzungen

• Die Begriffe des Testens, wie sie „Testen verstehen“ vermittelt: F.I.R.S.T., Test Scope, Test Doubles
• Ein Projekt, in dem PHPUnit läuft, wie nach „Startklar mit PHPUnit“; sonst arbeitest du am Übungsprojekt
• Grundkenntnisse in PHPStan sind hilfreich, aber nicht nötig
• Für die Übungen PHP 8.5, Composer und Git, alternativ Podman oder Docker mit dem mitgelieferten Containerfile

Das nimmst du mit

• Du legst fest, welche Erwartungen dein Projekt auf welcher Ebene prüft, und kannst es begründen
• Du hast eine Testrichtlinie, in der jede Regel einen Grund hat
• Du konfigurierst PHPUnit so, dass es Tests zurückweist, die nichts prüfen oder zu viel behaupten
• Du lässt PHPStan auch deinen Testcode analysieren, mit der Erweiterung, die PHPUnit kennt
• Du weißt, welche Regeln Werkzeuge prüfen und welche ins Review gehören
• Du nimmst ein Paket für dein eigenes Projekt mit: Teststrategie, Testrichtlinie, phpunit.xml und phpstan.neon für den Testcode

Verwandte Schulungen

Diese Schulung ist Teil der Lernpfade Einstieg ins Testen, Testvorgaben im Team.