4 Testgetriebene Entwicklung mit PHPUnit

Transkript

1 57 4 Testgetriebene Entwicklung mit PHPUnit»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: Test-First-Ansatz

2 58 4 Testgetriebene Entwicklung mit PHPUnit 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. Refactoring Unit Test PHPUnit 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. Erst automatisierte Tests machen die zum Erreichen des einfachsten Designs nötigen Änderungen am Code sinnvoll durchführbar. Ohne sie müsste jede Methode einer jeden Klasse von Hand getestet werden, wenn der Code einer Klasse geändert wurde. In der Java-Welt bildet JUnit 1 den De-facto-Standard unter den Frameworks für Unit Tests. JUnit definiert eine allgemeine Struktur für Testfälle, gibt dem Entwickler die nötigen Werkzeuge an die Hand, um diese auszuführen, und übernimmt so einen großen Teil der Arbeit. Unter 1

3 4. 2 Testfälle und Zusicherungen 59 dem Namen PHPUnit 2 habe ich eine PHP-Portierung von JUnit entwickelt, die über PEAR als Open-Source-Software bezogen werden kann. Test Frameworks wie PHPUnit und JUnit erlauben die strikte Trennung von Produktionscode und Testcode. Tests können gruppiert werden, die Ausführungsreihenfolge hat keinen Einfluss auf das Ergebnis der einzelnen Tests. Neben PHPUnit2, der aktuellen Version von PHPUnit für PHP 5, gibt es mit PHPUnit eine Version für PHP 4, die nicht so umfangreich wie die Implementierung für PHP 5 ist und nicht mehr weiterentwickelt wird. PHPUnit2 enthält das auf JUnit basierte Unit-Test-Framework sowie ein Frontend für die Verwendung von der Kommandozeile. Neben der Funktionalität von JUnit bietet PHPUnit2 unter anderem auch die Funktionen von junitour 3 für unvollständige Tests und TestDox 4 für die agile Dokumentation. Die Installation des PHPUnit2-Paketes gestaltet sich dank des PEAR- Installers recht komfortabel: pear install --alldeps PHPUnit2 Im Folgenden betrachten wir die von PHPUnit2 bereitgestellten Klassen und werden sehen, wie mit ihnen Unit Tests geschrieben und automatisiert ausgeführt werden können. Abb. 4-1 Das PHPUnit2-Paket installieren 4. 2 Testfälle und Zusicherungen Ein Testfall (englisch: Test Case) wird als öffentliche Methode, die keinen Parameter erwartet, in einer Klasse definiert, die die Schnittstelle PHPUnit2_Framework_Test implementiert. In der Regel wird hierzu eine Klasse verwendet, die sich von PHPUnit2_Framework_TestCase ableitet. Hierbei sind die folgenden Namenskonventionen zu beachten: Testfall Der Name einer Klasse, die die Schnittstelle PHPUnit2_Framework_Test implementiert und Testfälle enthält, endet mit dem Suffix Test. Der Name einer Testfallmethode beginnt mit dem Präfix test. Plant man seine Testfälle bei der Anwendungsentwicklung nach dem Test- First-Ansatz geschickt, so kann man auch den von Eiffel eingeführten Ansatz»Entwurf durch Vertrag«(englisch: Design-by-Contract 5 ) verfolgen. Hierbei wird die Zusammenarbeit von unterschiedlichen Programm

4 60 4 Testgetriebene Entwicklung mit PHPUnit teilen (beispielsweise Methoden) in einem Vertrag geregelt. Dieser enthält mit den Vorbedingungen Zusicherungen, die der Aufrufer einer Methode zu erfüllen hat, sowie mit den Nachbedingungen Zusicherungen, die die aufgerufene Methode einzuhalten hat. Auf diese Weise können Anforderungen an die Funktion der Methode im Quelltext festgehalten werden. In einer Programmiersprache wie PHP, die im Gegensatz zu Eiffel nicht über eine Sprachunterstützung für den Design-by-Contract-Ansatz verfügt, kann man den Vertrag mit Hilfe entsprechender Testfälle formulieren. Dies wollen wir uns am Beispiel einer Klasse, die ein Bankkonto repräsentieren soll, genauer ansehen. Der Vertrag der Klasse BankAccount verlangt die Einhaltung der folgenden Bedingungen: Der Kontostand ist zu Beginn Null. Der Kontostand kann nicht negativ werden. Zusätzlich zu diesen Vereinbarungen legen wir die Schnittstelle fest, über die die Klienten der Klasse BankAccount mit dieser kommunizieren können: getbalance() fragt den aktuellen Kontostand ab. setbalance($balance) setzt den Kontostand auf einen neuen Wert. depositmoney($amount) modelliert das Einzahlen von Geld auf das Konto. withdrawmoney($amount) modelliert das Abheben von Geld von dem Konto. Bevor wir den Produktionscode, also die Klasse BankAccount, schreiben, setzen wir die Vereinbarungen in Testfälle um ( Beispiel 4-1 ). Die Wahl von»sprechenden Namen«für die Testfallmethoden, die die einzelnen Vertragspunkte ausdrücken, wird sich später noch als nützlich erweisen (siehe Abschnitt 4.6 ). Beispiel 4-1 Die Testfälle für die Klasse BankAccount require_once 'BankAccount.php'; require_once 'PHPUnit2/Framework/TestCase.php'; class BankAccountTest extends PHPUnit2_Framework_TestCase { public function testbalanceisinitiallyzero() { $ba = new BankAccount; $this->assertequals(0, $ba->getbalance()); public function testbalancecannotbecomenegative() { $ba = new BankAccount; $ba->withdrawmoney(1);

5 4. 2 Testfälle und Zusicherungen 61 $this->assertequals(0, $ba->getbalance()); $ba = new BankAccount; $ba->setbalance(-1); $this->assertequals(0, $ba->getbalance()); Wir haben nun gesehen, welche äußere Form ein Testfall bei der Verwendung von PHPUnit haben muss, doch wie teilen wir PHPUnit innerhalb einer Testmethode mit, ob ein Testfall erfolgreich durchlaufen wurde oder nicht? Durch die Ableitung unserer Testfallklasse von PHPUnit2_Framework_TestCase erbt sie eine Reihe von Methoden, mit denen eine Zusicherung (englisch: Assertion) überprüft werden kann. Diese Zusicherungen werden am Ende des Rumpfes einer Testmethode eingesetzt, um einen Ist-Zustand mit einem Soll-Zustand zu vergleichen. Das Ergebnis dieser Überprüfung wird automatisch als Ergebnis des Testfalls für die spätere Auswertung gespeichert. PHPUnit stellt die folgenden Zusicherungsmethoden zur Verfügung: Zusicherungen assertcontains($needle, $haystack, $message = '') assertnotcontains($needle, $haystack, $message = '') assertequals($expected, $actual, $message = '', $delta = 0) assertnull($object, $message = '') assertnotnull($object, $message = '') assertsame($expected, $actual, $message = '') assertnotsame($expected, $actual, $message = '') asserttrue($condition, $message = '') assertfalse($condition, $message = '') assertregexp($pattern, $string, $message = '') assertnotregexp($pattern, $string, $message = '') asserttype($expected, $actual, $message = '') assertnottype($expected, $actual, $message = '') $needle $haystack $actual $expected $delta $object NULLNULL $actual $expected $conditiontrue FALSE $string $pattern $actual $expected Tabelle 4-1 Die Zusicherungsmethoden von PHPUnit

6 62 4 Testgetriebene Entwicklung mit PHPUnit Der optionale Parameter $message definiert die Nachricht, die beim Scheitern des Tests zurückgegeben wird. Wird er nicht angegeben, so wird eine Standardnachricht erzeugt. Nach dieser Übersicht über die möglichen Zusicherungsmethoden, die wir für die Umsetzung unserer Testfälle verwenden können, ist es an der Zeit, den eigentlichen Produktionscode zu schreiben. zeigt eine mögliche Implementierung der Klasse BankAccount, die den Anforderungen der Testfälle entspricht. Beispiel 4-2 Die Klasse BankAccount class BankAccount { private $fbalance = 0; public function getbalance() { return $this->fbalance; public function setbalance($balance) { if ($balance >= 0) { $this->fbalance = $balance; public function depositmoney($amount) { if (is_numeric($amount) && $amount >= 0) { $this->fbalance += $amount; public function withdrawmoney($amount) { if (is_numeric($amount) && $amount >= 0 && $this->fbalance >= $amount) { $this->fbalance -= $amount; 4. 3 Testfälle ausführen und zusammenfassen Testsuite Eine Gruppe von Testfällen, Testsuite genannt, wird mit der Klasse PHPUnit2_Framework_TestSuite zusammengefasst und ausgeführt. Hierfür gibt es zwei Möglichkeiten. Bei der Erzeugung eines Objektes der Klasse PHPUnit2_Framework_TestSuite wird dem Konstruktor der Name ei-

7 4. 3 Testfälle ausführen und zusammenfassen 63 ner Klasse übergeben, die sich von PHPUnit2_Framework_TestCase oder einer Kindklasse ableitet. In diesem Fall wird der Testsuite für jede Methode dieser Klasse, deren Name mit test beginnt, ein Testfall hinzugefügt. Bei der Erzeugung eines Objektes der Klasse PHPUnit2_Framework_TestSuite wird dem Konstruktor kein Parameter übergeben. In diesem Fall können der zu Beginn leeren Testsuite mit der Methode addtest($test) Testfälle hinzugefügt werden. Bei dem Parameter $test handelt es sich um eine Referenz auf ein Objekt einer Klasse, die die Schnittstelle PHPUnit2_Framework_Test implementiert. Für die Erzeugung eines solchen Objektes ist dem Konstruktor der Name der zu testenden Methode zu übergeben. Für die Ausführung der Testfälle einer Testsuite wird ein Objekt der Klasse PHPUnit2_Framework_TestResult benötigt, das die Ergebnisse der einzelnen Testfälle für die spätere Auswertung aufnimmt. Mit Hilfe des Beobachter-Entwurfsmusters, das wir in Kapitel 7 näher betrachten werden, kann der Testverlauf durch Objekte, die sich von PHPUnit2_Framework_TestListener ableiten, beobachtet werden. Mit dem für die Kommandozeile entwickelten TextUI TestRunner führen wir nun die Testfälle der Klasse BankAccountTest aus. Die Quelldateien BankAccount.php und BankAccountTest.php müssen hierfür entweder im aktuellen Verzeichnis oder im include_path liegen. phpunit BankAccountTest PHPUnit by Sebastian Bergmann... Time: Beobachter Abb. 4-2 Ausführen der Testfälle einer Testfallklasse OK (2 tests) Für die automatisierte Ausführung von Testsuiten bietet sich der direkte Aufruf der Methode PHPUnit2_TextUI_TestRunner::run() aus dem Quelltext der Testsuite heraus an. Durch die Möglichkeit, Instanzen von PHPUnit2_Framework_TestSuite ineinander zu schachteln, können die Testfälle hierarchisch organisiert werden: Eine Klasse Projekt_Tests_All- Tests ( Beispiel 4-3 ) nimmt die Testfälle des gesamten Projektes auf. Für jedes Paket des Projekt gibt es eine Klasse ( Beispiel 4-4 ), in der die Testfälle für die Klassen des Paketes zusammengefasst sind. Die einzelnen Testfälle sind in Klassen wie Projekt_Tests_Paket_Klasse ( Beispiel 4-5 ) implementiert.

8 64 4 Testgetriebene Entwicklung mit PHPUnit Beispiel 4-3 Die Klasse Projekt_Tests _AllTests if (!defined('phpunit2_main_method')) { define( 'PHPUnit2_MAIN_METHOD', 'Projekt_Tests_AllTests::main' ); require_once 'PHPUnit2/Framework/TestSuite.php'; require_once 'PHPUnit2/TextUI/TestRunner.php'; require_once 'Projekt/Tests/Paket/AllTests.php'; class Projekt_Tests_AllTests { public static function main() { PHPUnit2_TextUI_TestRunner::run(self::suite()); public static function suite() { $suite = new PHPUnit2_Framework_TestSuite('Projekt'); $suite->addtest(projekt_tests_paket_alltests::suite()); return $suite; if (PHPUnit2_MAIN_METHOD == 'Projekt_Tests_AllTests::main') { Projekt_Tests_AllTests::main(); Die AllTests-Klassen implementieren einen Mechanismus, der der statischen Methode main() von Java entlehnt ist. Die Ausführung der Quelltextdatei einer solchen Klasse durch den PHP-Interpreter führt somit zur Ausführung der entsprechenden Testfälle. Beispiel 4-4 Die Klasse Projekt_Tests_ Paket_AllTests if (!defined('phpunit2_main_method')) { define( 'PHPUnit2_MAIN_METHOD', 'Projekt_Tests_Paket_AllTests::main' ); require_once 'PHPUnit2/Framework/TestSuite.php'; require_once 'PHPUnit2/TextUI/TestRunner.php'; require_once 'Projekt/Tests/Paket/Klasse.php';

9 4. 4 Automatische Generierung von Testfallklassen 65 class Projekt_Tests_Paket_AllTests { public static function main() { PHPUnit2_TextUI_TestRunner::run(self::suite()); public static function suite() { $suite = new PHPUnit2_Framework_TestSuite( 'Projekt / Paket' ); $suite->addtestsuite('projekt_tests_paket_klasse'); return $suite; if (PHPUnit2_MAIN_METHOD == 'Projekt_Tests_Paket_AllTests::main') { Projekt_Tests_Paket_AllTests::main(); require_once 'PHPUnit2/Framework/TestCase.php'; require_once 'Projekt/Paket/Klasse.php'; class Projekt_Tests_Paket_Klasse extends PHPUnit2_Framework_TestCase { public function testmethode() { $t = new Projekt_Paket_Klasse; $this->asserttrue($t->methode('test')); Beispiel 4-5 Die Klasse Projekt_Tests_ Paket_Klasse //... Wir haben nun gesehen, wie für PHP-Klassen Testfälle für die automatische Ausführung und Auswertung mit PHPUnit geschrieben werden. Wer mehr über das Testen von Software mit Unit Tests lesen möchte, dem sei das Buch»Unit Tests mit Java«von Johannes Link und Peter Fröhlich [Link2005] empfohlen. Dieses befasst sich mit der Entwicklung von Unit Tests für Java mit JUnit, viele der Ideen und Lösungen lassen sich jedoch problemlos auf PHP und PHPUnit übertragen Automatische Generierung von Testfallklassen PHPUnit bietet einige Leistungsmerkmale, die nicht Bestandteil von JUnit sind. Hierzu gehören unter anderem die automatische Generierung von

10 66 4 Testgetriebene Entwicklung mit PHPUnit Testfallklassen aufgrund der zu testenden Klasse, die Unterstützung für unvollständige Test-Implementierungen, die Code-Coverage-Analyse von PHP-Applikationen sowie die Integration von TestDox. Möchte man für eine bestehende Klasse Testfälle schreiben, so kann PHPUnit ein Grundgerüst für eine Testfallklasse generieren. Auf diese Weise spart man lästige Tipparbeit und kann sich auf das Schreiben der eigentlichen Testfallmethoden konzentrieren. Für die Klasse Sample ( Beispiel 4-6 ) generieren wir beispielsweise mit dem folgenden Aufruf des PHPUnit-Kommandozeilenwerkzeugs das Grundgerüst für eine entsprechende Testfallklasse SampleTest ( Beispiel 4-7 ). Abb. 4-3 Automatische Generierung einer Testfallklasse Beispiel 4-6 Die Klasse Sample Beispiel 4-7 Die automatisch generierte Klasse SampleTest phpunit --skeleton Sample PHPUnit by Sebastian Bergmann. Wrote test class skeleton for Sample to SampleTest.php. class Sample { public function dosomething() { if (!defined("phpunit2_main_method")) { define("phpunit2_main_method", "SampleTest::main"); require_once "PHPUnit2/Framework/IncompleteTestError.php"; require_once "PHPUnit2/Framework/TestCase.php"; require_once "Sample.php"; /** * Test class for Sample. * Generated by PHPUnit2_Util_Skeleton * on at 02:19:00. */ class SampleTest extends PHPUnit2_Framework_TestCase { public static function main() { require_once "PHPUnit2/Framework/TestSuite.php"; require_once "PHPUnit2/TextUI/TestRunner.php"; $suite = new PHPUnit2_Framework_TestSuite("SampleTest"); $result = PHPUnit2_TextUI_TestRunner::run($suite); /** Implement testdosomething().

11 4. 5 Code-Coverage-Analyse von PHP-Applikationen 67 */ public function testdosomething() { throw new PHPUnit2_Framework_IncompleteTestError; if (PHPUnit2_MAIN_METHOD == "SampleTest::main") { SampleTest::main(); php SampleTest.php PHPUnit by Sebastian Bergmann. I Time: There was 1 incomplete testcase: 1) testdosomething OK, but incomplete test cases!!! Tests run: 1, incomplete test cases: 1. Die automatisch generierte Testklasse nutzt die Ausnahme PHPUnit2_Framework_IncompleteTestError (und damit die Unterstützung für unvollständige Test-Implementierungen von PHPUnit) in ihren Testfallmethoden und signalisiert so dem Testsystem, dass der entsprechende Testfall noch nicht implementiert wurde. Würden die Testfallmethoden stattdessen mit einem leeren Rumpf generiert, so würde dies den falschen Eindruck vermitteln, dass die Testfälle fehlerfrei ausgeführt würden Code-Coverage-Analyse von PHP-Applikationen Ist die Xdebug 6 -Erweiterung für PHP installiert, so kann PHPUnit bei der Ausführung der Testfälle darüber Buch führen, welche Zeilen des zu testenden Codes für die einzelnen Testfälle ausgeführt (und somit von einem Test»abgedeckt«) werden. Diese Information gibt Aufschluss darüber, ob der gesamte Produktionscode von den geschriebenen Testfällen getestet wird. Ist man sich sicher, dass die Testsuite vollständig ist, und es werden dennoch nicht alle Zeilen des Produktionscodes bei der Ausführung der Testfälle erreicht, so sind diese mit einiger Wahrscheinlichkeit redundant und können möglicherweise entfernt werden. Abbildung 4-4 zeigt den Aufruf des PHPUnit-Kommandozeilenwerkzeugs mit dem Parameter --coverage-html für die Erstellung einer Code- Coverage-Analyse im HTML-Format. Dieser ist zu entnehmen, dass die 6

12 68 4 Testgetriebene Entwicklung mit PHPUnit Methoden getbalance(), setbalance() und withdrawmoney() aufgerufen werden, die Methode depositmoney($amount) aber noch von keinem Testfall abgedeckt ist. Mit Hilfe von Zusicherungen haben wir den Vertrag der Klasse BankAccount () in die Testfälle der Klasse BankAccountTest () geschrieben. Hierbei haben wir sprechende Namen wie testbalanceisinitiallyzero gewählt, um einen Bezug zwischen Vertragspunkt und Testfallmethode herzustellen. Für die Erstellung von Testreports können diese Informationen mit der TestDox-Funktionalität von PHPUnit extrahiert werden. Diese ist angelehnt an die gleichnamige Erweiterung für agile Dokumentation mit JUnit. Das PHPUnit-Kommandozeilenwerkzeug erzeugt auf Wunsch (Parameter --testdox-html und --testdox-text) einen Testreport in TestDox- Abb. 4-4 Code-Coverage- Analyse für die Klasse BankAccount phpunit --coverage-html BankAccount.html BankAccountTest PHPUnit by Sebastian Bergmann... Time: OK (2 tests) 4. 6 TestDox Agile Dokumentation

13 4. 6 TestDox 69 Notation. Als Ausgabeformat kann HTML oder Text gewählt werden. Abbildung 4-5 zeigt die Textausgabe für die BankAccountTest-Klasse ( Beispiel 4-1 ). phpunit --testdox-text BankAccount.txt BankAccountTest.php PHPUnit by Sebastian Bergmann... Time: Abb. 4-5 TestDox-Ausgabe für die Klasse BankAccountTest OK (2 tests) cat BankAccount.txt BankAccount - Balance is initially zero - Balance cannot become negative Damit TestDox seine Arbeit korrekt verrichten kann, müssen die Namen der Testmethoden in der Studly-Caps-Notation vorliegen. TestDox erkennt den Beginn eines neuen Worts anhand der Großbuchstaben: aus»testbalanceisinitiallyzero«wird so»balance is initially zero«.