Modul C · Qualität & Sicherheit · Lektion C1

Tests und Codequalität in PHP: PHPUnit, statische Analyse und PSR

Aktualisiert am 24.09.20263 Min. Lesezeit

Warum überhaupt testen?

Tests sind ausführbare Beschreibungen dessen, was dein Code tun soll. Sie geben dir den Mut, Code zu verbessern, weil du sofort merkst, wenn etwas nicht mehr stimmt. Beim Upgrade auf eine neue PHP-Version – siehe PHP-Versionen und Support – sind sie oft der Unterschied zwischen einem ruhigen Nachmittag und einer langen Nacht.

Die Testpyramide

Die Grafik oben zeigt ein verbreitetes Denkmodell. Unten stehen viele kleine Unit-Tests, die einzelne Funktionen oder Klassen isoliert prüfen. Sie sind schnell und zeigen genau, wo ein Fehler liegt. Darüber stehen weniger Integrationstests, die mehrere Teile zusammen prüfen, etwa eine Klasse samt Datenbank. Ganz oben stehen wenige End-to-End-Tests, die die Anwendung wie ein Mensch im Browser bedienen. Sie sind am realistischsten, aber auch am langsamsten und anfälligsten.

PHPUnit: der Standard für Unit-Tests

PHPUnit wurde von Sebastian Bergmann entwickelt; die erste Version erschien bereits 2001. Es folgt dem xUnit-Prinzip, das man aus anderen Sprachen kennt. Ein Test ist eine Klasse, jede Testmethode prüft einen Fall:

<?phpdeclare(strict_types=1);use PHPUnit\Framework\TestCase;final class NotenrechnerTest extends TestCase{    public function testDurchschnittWirdGerundet(): void    {        class="va">$rechner = new Notenrechner();        class="va">$this->assertSame(2.3, class="va">$rechner->durchschnitt([2, 2, 3]));    }    public function testLeereListeWirftException(): void    {        class="va">$this->expectException(InvalidArgumentException::class);        (new Notenrechner())->durchschnitt([]);    }}

Installiert wird PHPUnit über Composer als Entwicklungsabhängigkeit, ausgeführt mit vendor/bin/phpunit. Eine Alternative mit knapperer Syntax ist Pest, das auf PHPUnit aufbaut.

Statische Analyse: Fehler finden, ohne Code auszuführen

Werkzeuge wie PHPStan und Psalm lesen deinen Code und prüfen ihn auf Widersprüche: Wird eine Methode aufgerufen, die es nicht gibt? Kann eine Variable an dieser Stelle null sein? Passt der Rückgabetyp? Beide arbeiten mit Stufen – du fängst streng genug an, dass das Ergebnis nützlich ist, und erhöhst die Stufe nach und nach.

Statische Analyse ersetzt keine Tests. Sie findet Typfehler und Unstimmigkeiten, aber nicht, ob deine Geschäftslogik richtig rechnet. Zusammen ergeben beide ein sehr engmaschiges Netz. Je mehr Typangaben dein Code hat, desto mehr kann die Analyse leisten – ein weiterer Grund, von Anfang an typisiert zu programmieren.

Coding Standards und PSR

Code wird öfter gelesen als geschrieben. Einheitliche Formatierung sorgt dafür, dass sich jeder im Team schnell zurechtfindet. Die PHP-FIG (Framework Interoperability Group) veröffentlicht dafür die PHP Standards Recommendations, kurz PSR. Einige wichtige:

Die Formatierung musst du nicht von Hand einhalten. PHP_CodeSniffer und PHP-CS-Fixer prüfen und korrigieren sie automatisch, die meisten Editoren können das beim Speichern erledigen.

Alles zusammen: automatisch bei jeder Änderung

Ihre volle Wirkung entfalten die Werkzeuge, wenn sie automatisch laufen – bei jedem Push in die Versionsverwaltung, etwa über GitHub Actions oder GitLab CI. Ein typischer Ablauf: Coding Standard prüfen, statische Analyse, Tests. Schlägt ein Schritt fehl, wird die Änderung nicht übernommen.

Für den Unterricht ist das ein dankbares Thema, weil Lernende unmittelbar Rückmeldung bekommen. Anregungen dazu gibt PHP im Unterricht. Die Dokumentation zu PHPUnit findest du auf phpunit.de.