Professionelle Softwareentwicklung mit PHP 5 - Objektorientierung – Entwurfsmuster – Modellierung – Fortgeschrittene Datenbankprogrammierung

4 Testgetriebene Entwicklung mit PHPUnit (S. 57-58)

»The fewer tests you write, the less productive you are and the less stable your code becomes.«

Erich Gamma

4. 1 Einleitung

Das Testen von Software ist wichtig. Doch obwohl dies allen Softwareentwicklern bewusst sein dürfte, verhalten sich die meisten nicht entsprechend. Sie testen ihre Software entweder gar nicht, oder erst, wenn es zu spät ist. Vorurteile und vorgeschobene Gründe wie die folgenden führen zu einem Teufelskreis, dem nur schwer zu entkommen ist:

»Ich habe keine Zeit zum Testen.«

»Testen von Software ist langweilig und stupide.«

»Mein Code ist praktisch fehlerfrei, auf jeden Fall gut genug.«

»Die Testabteilung testet. Die können das eh viel besser.«

Im Extreme Programming, das zu den so genannten agilen oder leichtgewichtigen Software-Entwicklungsprozessen gehört, wird dieser Teufelskreis durchbrochen, und zwar durch die Forderung, den Test zuerst zu schreiben und danach den Code, auf den sich der Test bezieht (Test-First- Ansatz). Das Vertrauen in den Code wird erhöht, die Auswirkungen von Änderungen an einer Stelle auf den restlichen Code können schnell und zuverlässig überprüft werden. Darüber hinaus führt diese Vorgehensweise zu Einfachheit, Testbarkeit und Wartbarkeit des Codes.

Das Schreiben von neuem Produktionscode gestaltet sich beim Test- First-Ansatz in zwei Schritten:

1. Bevor neuer Produktionscode geschrieben wird, wird ein entsprechender Test geschrieben, der diesen Code motiviert. Dies sorgt einerseits dafür, dass es zu keinem Zeitpunkt Produktionscode gibt, für den kein Test existiert. Andererseits setzt sich der Programmierer beim Formulieren des Tests mit den Anforderungen an den zu schreibenden Code auseinander.

2. Es wird nur so viel Produktionscode geschrieben, wie es der Test verlangt. Mit anderen Worten: Läuft der Test, steht der Code.

Ohne die automatisierte Ausführung von Entwicklertests auf Modulebene (englisch: Unit Tests), wie wir sie in diesem Kapitel diskutieren wollen, ist das Refactoring (deutsch: »neu herstellen«) von Code nur schwer möglich. Martin Fowler definiert Refactoring als »den Prozess, ein Softwaresystem so zu ändern, dass sich das externe Verhalten nicht ändert, jedoch die innere Struktur verbessert wird«. [Fowler1999] Hierzu gehören unter anderem Änderungen an der Struktur des Codes wie Umbenennung von Klassen und Methoden oder die Extraktion von Code einer Klasse in eine neue Klasse.

Der Begriff des Unit Tests kommt ursprünglich aus der prozeduralen Programmierung. Dort entsprach die zu testende Programmeinheit einer Funktion oder Prozedur. In der objektorientierten Programmierung ist diese Definition weiter gefasst, so dass von einer einzelnen Methode, über eine gesamte Klasse bis hin zum gesamten System Programmeinheiten mit einem Unit Test getestet werden können. Unit Tests ermöglichen das ständige Refactoring von Code auf der Basis der folgenden Regeln:

1. Alle Unit Tests laufen.
2. Der Code kommuniziert alle seine Designkonzepte.
3. Der Code enthält keine Redundanz.
4. Der Code enthält, unter Berücksichtigung der obigen Regeln, die geringstmögliche Anzahl an Klassen und Methoden.