Unit-Tests für PHP schreiben

Unit-Testing ist vor allem bei größeren Softwareprojekten eine essenzielle Technik, die im Repertoire des Entwicklers nicht mehr fehlen darf. Das Standardwerkzeug unter PHP ist das Kommandozeilen-Programm PHP Unit [1]. Daneben existieren ein paar alternative Werkzeuge, die aber mangels Verbreitung und wegen ihres geringen Funktionsumfangs derzeit nicht empfehlenswert sind.

Tests für PHP-Projekte

Dieser Artikel erläutert, wie PHP-Entwickler das Testen mit PHP Unit in ihre eigenen Projekte integrieren. Dazu dient ein kleines Codebeispiel des Autors, der am Horde-Framework [2] und dessen Anwendungen mitarbeitet. Das Softwareprojekt ging mit 13 Jahren Tradition, über einer Million Codezeilen und 0 Prozent Testabdeckung an die Einführung von Unit-Tests. Mittlerweile existieren über 3000 Tests, die immer wieder helfen Fehler frühzeitig zu entdecken. Auf den meisten Distributionen installiert der Admin PHP Unit, indem er den Paketmanager auffordert »phpunit« einzuspielen. Als distributionsunabhängigen Standardweg der Installation gibt das PHP-Unit-Projekt selbst die PEAR-basierte Installation vor. Die Installation besteht in diesem Fall aus folgenden Kommandos:

pear channel-discover pear.phpunit.de
pear channel-discover components.ez.no
pear channel-discover pear.symfony-project.com
pear install phpunit/PHPUnit

Als Programmierbeispiel dient ein minimaler Client für Gravatar, einen Onlinedienst, der seinen Benutzern individuelle Avatar-Bildchen zum Einbinden in Foren, Blogs und Websites zur Verfügung stellt [3]. Dabei geht es – wie häufig bei der Serversprache PHP – um die Kommunikation mit externen Systemen.

Der Code erhält die Form eines Horde-Pakets mit dem Namen »Horde_Service_Gravatar« . Im Horde-Git-Repository [4] lässt sich das Beispiel in kleinen Schritten (Git-Tags »hgs_step0« bis »hgs_step15« ) nachverfolgen, was in diesem Artikel aus Platzgründen nicht in gleicher Ausführlichkeit möglich ist.

Außerdem gibt das Horde-Projekt Strukturen für die Organisation der Codedateien im Paket vor. Beispielsweise ist vorgeschrieben, den Bibliothekscode und die Tests getrennt in den Verzeichnissen »lib« und »test« abzulegen (siehe Abbildung 1). Das erleichtert sowohl PHP Unit als auch anderen Programmierern das Auffinden der Tests. Die von Horde vorgegebene Struktur erlaubt zudem Autoloading nach PSR-0 [5].

Abbildung 1: Die Verzeichnisstruktur trennt PHP-Bibliothekscode und Tests.

Das oben angesprochene »lib« -Verzeichnis muss sich für die folgenden Beispiele aber im Include-Pfad von PHP befinden. Aus dem Arbeitsverzeichnis »Service _Gravatar/test/Horde/Service/Gravatar« erreicht der Entwickler das am einfachsten, indem er die Option »-d include_path ="../../../../lib:/usr/share/php"« an den »phpunit« -Aufruf anhängt. »/usr/share/php« verweist dabei auf das Verzeichnis, das die Klassen von PHP Unit bereithält.

Testgetrieben

Das Programmieren beginnt mit einer leeren Definition der Zielklasse in »Service_Gravatar/lib/Horde/Service/Gravatar.php« :

class Horde_Service_Gravatar
{
}

Das von Grund auf neu geschriebene Beispiel erlaubt es, völlig "Test-driven" zu programmieren, also die Tests vor der eigentlichen Implementierung zu schreiben [6]. Das mag im Alltag nicht einfach erscheinen: Vielleicht ist der Code schon älter und lädt ohne nennenswerte Testabdeckung nicht gerade zur testgetriebenen Weiterentwicklung ein.

Manche Entwicklungsaufgaben eignen sich auch weniger für diese Methode als andere: So ist Code, der über HTTP, IMAP, SQL oder Ähnliches mit einem anderen System kommuniziert, deutlich schwieriger zu testen. Wer sich an die Empfehlungen der Unit-Test-Puristen hält, wird aber im Normalfall von besser wartbarem Code profitieren.