Testgetriebene Entwicklung mit JUnit

Transkript

1 Master Technische Informatik Seminar Informatik Thema Testgetriebene Entwicklung mit JUnit Von Yassine El Amrani Referent Prof. Dr. Hans Nissen - 1 -

2 Inhaltsverzeichnis 1 Einleitung Tests in der Software Entwicklung Tests in der Modellen der Softwareentwicklung Glossar Testgetriebene Entwicklung Was ist Testgetriebene Entwicklung? Phasen der Testgetriebene Entwicklung TDD Beispiel Vorteile und Nachteile von TDD Vorteile von TDD Nachteile von TDD Tools zur Unterstüzung bei TDD xunit TDD Akzeptanztest Continous Build Code Coverage Konzepte und Patterns für TDD Test Auswahl Strategien Komponenten-Rahmen Tests versus Komponenten-Logik Tests: Bekannte versus unbekannte Terrain Gültige Klassen Tests versus ungültige Klassen Test Implementierungsstrategien Funktionalität Simulieren Triangulation Klare Implementierung Weitere TDD Richtlinien Kleinere aber sichere Schritte Refactoring nicht überspringen Schnell zu grün TDD Patterns Test Isolierung Asserts zuerst Test Daten Testen mit JUnit Download und Installation JUnit-Klassendiagramm TestCase-Beispiel TestSuite-Beipsiel JUnit mit Eclipse JUnit Erweiterungen Zusammenfassung

3 1 Einleitung Testen ist sicherlich ein wichtiger und ein unverzichtbarer Bestandteil in dem modernen Softwareentwicklungsprozess geworden. Darüber hinaus, hängt die Qualität des Softwareproduktes maßgeblich von dem Wert ab, den auf das Testen während des Softwareentwicklungsprozesses gelegt wird. Aber wie das Testen in den Softwareprojekten praktiziert wird, hängt von der Art des angewendeten Entwicklungsprozesses ab. Es existiert mehrere Modelle der Softwareentwicklung. Die bekanntesten und weit verbreitesten sind sicherlich das Wasserfall-Modell und die Extremprogrammierung (engl. Extrem Programming XP). Bei dem Wasserfall-Modell wird die komplett implementierte Software in einer eigenständigen Phase ganz am Ende des Prozesses getestet. Anders bei dem Extrem Programmierungs- Modell, wird das Softwareprodukt in sehr kleinen Schritten implementiert, und nach jedem Schritt wird der implementierte Kode direkt getestet. Aus diesem Konzept ist ein neues Entwicklungsmodell entstanden, nämlich das Modell der Testgetriebene Entwicklung (engl. Test Driven Development kurz TDD). Hier spielen die Tests eine sehr wichtige Rolle in dem gesamten Entwicklungsprozess, weil die komplette Implementierungsphase durch die Tests gesteuert wird. Anders als bei vielen Modellen, wo die Testphase meistens als Endmailstein festgelegt wird. In diesem Vortrag wird das Modell Testgetriebene Entwicklung näher betrachtet. Im ersten Kapitel werden einige Grundlagen definiert. Dann im zweiten Kapitel wird TDD beschrieben und anhand eines Beispiels erklärt. Anschließend wird die Unit Test Framework für Java JUnit vorgestellt

4 2 Tests in der Software Entwicklung 2.1 Tests in der Modellen der Softwareentwicklung Die Fachliteratur und die Praxis unterscheiden zwischen mehreren Softwareentwicklungs- Prozesse. Zu den bekanntesten Prozessen gehören u. A. das Wasserfall-Model, das V-Modell und das inkrementelles Modell. Die meisten Modelle haben ähnliche Entwicklungsphasen, aber sie unterliegen unterschiedliche Voraussetzungen, um zur nächsten bzw. zur vorherigen Phase zu übergehen. Bei den genannten Modellen wird zwar immer eine Testphase vorgesehen, ist aber zu feststellen, dass sie meistens in dem Entwicklungsprozess nach hinten geschoben wird. Auf den nächsten zwei Abbildungen ist das sehr gut zu erkennen. Abbildung 1 zeigt, dass die Testphase sowohl bei dem Wasserfall-Modell als auch bei dem Inkrementellen-Modell als eigenständige Entwicklungsphase geplant wird. Die Tests werden erst vor der Abnahme des Software Produktes durchgeführt. Also direkt vor der Betriebsnahme. Dabei wird die Software als Gesamtpacket an allen funktionaliätetn auf einer prdouktiv ähnlichen Betriebsumgebnung getestet. Und bei Entdeckung von Fehlern wird die Software wieder zur Implementierung zum Beheben von den Fehlfunktionen zurückgebracht. Dieser Zyklus wird dann solange wiederholt bis das Softwareprodukt fehlerfrei ist. Abbildung 1: Testphase in Wasserfall-Model und Inkrementelle-Modell Das Inkrementelle-Modell und vor allem das klassische Wasserfall-Modell werden in der Praxis sehr oft bei der Software Entwicklung eingesetzt. Man muss aber festellen, dass die - 4 -

5 verspätete Testphase einen großen Nachteil ist. Denn man erfährt erst ganz am Ende der Entwicklung kurz vor der Betriebsnahme, ob was man gedacht hat und implementiert hat richitg ist oder nicht. Was dazu führen könnte, dass die zeitliche Projektplannung durcheinander gebracht werden könnte. Anders bei dem V-Modell (Abbildung 2) ist die Testphase in mehreren Phasen aufgeteilt, wobei für jede Entwicklungsphase entsprechend eine Testphpase vorgesehen wird. Die Testphasen unterscheiden sich in dem Testziel, der Testmethoden, dem Testobjekt, und den Testwerkzeuge. Im nächsten Abschnitt sind sie genauer definiert. Diese Aufteilung der Testphasen, bringt das Vorteil, dass eine höhere Testabdeckung erreicht wird. Außerdem können die einzelnen Testphasen parallel zur der entsprechenden Entwicklungsphase gestartet werden. Dadurch kann viel Zeit gewonnen werden, und vor allem kriegt man früh einen feedback zur gesammten Entwicklung. Abbildung 2: Testphase in V-Modell - 5 -

6 2.2 Glossar In diesem Abschnitt werden einige Begriffe erläutert, die in dem Software-Testen wichtig sind. White-Box-Tests Ist eine Testmethode, wo die Definition der Tests auf den inneren Aufbau des Testobjekts basiert. D. h.. bei diesem Verfahren wird versucht, durch die erstellten Tests den Ablauf des Testobjekts zu steuern. Das Ziel ist den kompletten Verhalten des Testobjekts durch Tests abzudecken. Black-Box-Tests Ist ein Testverfahren, wo die innere Struktur und das Verhalten des Testobjekts unbekannt bleiben. Die Tests basieren nur auf die funktionalen und nicht-funktionalen Anforderungen, die spezifiziert worden. Dabei laufen die Tests meistens so ab, dass Eingaben an dem Testobjekt übergegeben werden und die zurückgegebenen Werte mit den erwarteten Ergebnissen verglichen werden. Unit Tests Ein Unit Test ist ein vom Entwickler selbst geschriebenes Stück Code, das die Aufgabe hat, eine bestimmte kleine Funktionalität zu untersuchen. Es dient zur Überprüfung, ob der implementierte Code genau macht, was man davon erwartet hat. Ein Unit Test hat meistens die Aufgabe die Funktionalität einer einzigen Methode zu testen. Komponententest Bei dem Komponententest werden die einzelnen Komponenten einer Software getestet. Eine Komponente einer Software ist zum Beispiel eine Klasse. Dabei werden die Komponenten isoliert getestet, also ohne Interaktion mit anderen Komponenten. Das Ziel des Komponententests ist die Sicherstellung, dass alle Software-Module getrennt betrachtet richtig implementiert worden sind

7 Integrationstest Die Aufgabe bei dem Integrationstest ist, das Zusammenspiel der einzelnen Komponenten eines komplexen Systems zu testen. Also anders als bei dem Komponententest, werden hier die einzelnen Komponenten nicht mehr als isolierte Komponenten gesehen, sondern als Teil eines ganzen Systems. Der Integrationstest setzt voraus, dass alle miteinander interagierte Komponenten vorhanden sind. Ist das nicht der Fall, müssen die fehlenden Komponenten simuliert werden. Die simulierten Komponenten nennt man Mock-Objeckte. Systemtest Bei dem Systemtest wird das gesamte System getestet. Dabei werden alle funktionalen und nicht-funktionalen Anforderungen aus der Spezifikation untersucht, ob sie richtig umgesetzt worden sind. Hier finden die Tests in einer Testumgebung statt, die ähnlich der Produktivumgebung ist. Abnahmetest Der Abnahmetest kann vom Kunden selbst ausgeführt werden, oder wird zumindest bei seiner Anwesenheit durchgeführt. Daher ist der Abnahmetest mehr als eine Vorführung als ein Test zu betrachten. Also hier wird einfach dem Kunden demonstriert, dass alle angeforderten Funktionalitäten erfüllt sind. Die Testumgebung entspricht genau der späteren Produktivumgebung des Kunden

8 3 Testgetriebene Entwicklung 3.1 Was ist Testgetriebene Entwicklung? Testgetriebene Entwicklung (engl. Test-Driven Developement kurz TDD) ist eine Technik der Software Entwicklung, wo die Tests als Leitfaden in der gesamten Entwicklung, oder präziser, in der Implementierungsphase genommen werden. D. h. die Tests geben an, was der zu implementierende Code an funktionalen oder auch nicht-funktionalen Anforderungen erfüllen soll. Was bedeutet aber auch, dass keine Zeile Code existieren kann, ohne die zugehörigen Tests. Das führt dazu, dass die Aufgabe entsteht, während der gesamten Implementierungsphase eine große Sammlung von Tests zu pflegen. Diese Sammlungen von Tests, Tests-Suites genannt, sorgen für das richtige Verhalten der Software entweder nach Implementierung neuer Funktionalitäten oder Änderung von bestehendem Code. Also kein Code geht in der Produktion bis er seine zugehörigen Tests besitzt. Und so wird die Qualität des gesamten Systems verbessert, und den Entwicklern die Sicherheit gegeben, dass sie alle Anforderungen richtig implementiert haben. Außerdem wird sichergestellt, dass der neue oder geänderte Code andere Funktionalitäten nicht beeinflusst hat. Das wichtigste Grundsatz in der Testgetriebene Entwicklung ist, dass immer erst der Testcode geschrieben wird, bevor der eigentliche Programmcode implementiert wird. Natürlich wird dieser Testcode am Anafang fehlschlagen, weil ja noch kein Code existiert, der diese Tests erfüllt. Im nächsten Schritt werden die von den Tests erwarteten Funktionalitäten implementiert, so dass die Tests erfolgreich durchlaufen

9 3.2 Phasen der Testgetriebene Entwicklung Abbildung 3: Phasen der Testgetriebene Entwicklung Die vorherige Abbildung zeigt die Phasen der Testgetriebene Entwicklung. Als erster Schritt werden die Tests aus den spezifizierten Anforderungen definiert und geschrieben. Damit stellt man die Anforderungen an den Code, die er erfüllen soll. Und weil ja noch kein Code existiert, die diese Tests erfüllt, fallen sie erstmal aus. Danach wird der Code geschrieben, der das gewünschte Verhalten implementiert. Hier kann man zwischen den Beiden Phasen hin und her umschalten, in dem man wenig Tests schreibt dann wenig Code implementiert, dann wieder andere Tests schreibt und den zugehörigen Code und so weiter. Durch die kleinen Schritte wird die Implementierung einfacher, und die Komplexität der Probleme vermindert. Nach der Implementierung laufen die Tests erfolgreich durch, und damit wird ein TDD- Zyklus abgeschlossen. Wobei wiederholt sich dieser Zyklus mit jeder neuen Anforderung. Bei geänderten Anforderungen müssen die vorhandenen Tests und Code in derselben Reihenfolge angepasst werden

10 3.3 TDD Beispiel In diesem Kapitel wird anhand eines konkreten Beispiels demonstriert, wie die Testgetriebene Entwicklung in der Praxis angewendet wird. Das Beispiel wurde aus dem Buch [KBT02] entnommen. Dabei werden ganz klar die Schritte von TDD einzeln beschrieben: 1. Schnell ein Test hinzufügen 2. Alle Tests ausführen und sehen, dass der neu hinzugefügte Test ausfällt. 3. Wenig Code Änderungen machen 4. Alle Tests noch mal ausführen, und sehen, dass alle erfolgreich durchlaufen 5. Duplikate Tests wegräumen Die Aufgabe besteht in dem Beispiel eine Multi-Währung Geld Klasse zu implementieren, die folgende Bericht ermöglicht: Firma Aktien Preis Total IBM USD USD Novartis CHF CHF Total USD Wobei ebenfalls ein Umrechnungskurs spezifiziert werden muss: Von Nach Rate CHF USD 2 Aus den vorherigen Anforderungen, werden die Tests definiert und geschrieben, die sicherstellen sollen, dass die spezifizierten Funktionalitäten richtig implementiert wurden: Test 1: Summe zwei Beträge unterschiedlicher Währungen, mit der Angabe der Umrechnungskurs Beispiel: 5 $ + 10 CHF = 10 $ (Rate 2:1) Test 2: Multiplikation von einer Anzahl von Aktien mit dem Preis Beispiel: 5 $ * 2 = 10 $

11 Test 1: public void testmultiplication() { Dollar five= new Dollar(5); five.times(2); assertequals(10, five.amount); Dieser Test kann natürlich erstmal nicht kompiliert werden. Aufgrund der folgenden Compiler Fehler: 1. Klasse Dollar nicht definiert 2. Konstruktor Dollar() nicht definiert 3. Methode time(int) nicht definiert 4. Attribut amount nicht definiert Und damit sind die ersten beiden Phasen aus dem TDD-Zyklus abgeschlossen (Abbildung 3). Als nächster Schritt soll gerade so viel Code geschrieben werden, dass der Compiler nicht mehr Fehler rauswerft. Aber der Test soll weiter fehlschlagen, und das ist genau das Ziel. D. h. der Test soll nur fehlschlagen, weil die gewünschten Funktionalitäten noch nicht implementiert sind. Man muss hier erwähnen, dass in der Testgetriebene Entwicklung ganz typisch ist, in kleinen Schritten die einzelnen Übersetzungsfehler beseitigt werden. Folgender Code erfüllt dieses minimale Ziel: Class Dollar { int amount; Dollar (int amount) { void time (int multiplier) {

12 Jetzt wenn wir die Tests noch mal ausführen, meldet der Compiler zwar keine Fehler mehr, aber die Tests schlagen fehl. Und das ist genau das gewünschte Ziel. Und wenn wir die JUnit Framework mit graphischer Oberfläche einsetzten würden (mehr dazu Kapitel 4), würden wir den berühmten roten JUnit Testbalken sehen. Abbildung 4: Der rote JUnit-Testbalken Der zeigt an, dass die Tests erfolgreich übersetzt worden, und die Tests fehlschlagen. Das bedeutet aber nicht, dass wir keine Fortschritte gemacht haben. Im Gegenteil, in der Testgetriebene Entwicklung heißt es, dass man einen Schritt in der Implementierung weiter gekommen ist. Und jetzt als nächster Schritt müssen die erwarteten Funktionalitäten implementiert werden, um die Tests zu erfüllen. Und hier wieder, was typisch dieser Entwicklungsstil ist, soll es wirklich nur programmiert werden, was zur Erfüllung der Tests notwendig ist, und nicht mehr nicht weniger. Für unser Beispiel würde folgender Code die Tests erfüllen:

13 Class Dollar { int amount = 10; Dollar (int amount) { void time (int multiplier) { Wenn wir jetzt die Tests ausführen, laufen sie erfolgreich durch, und kriegen wir die gewünschten grünen Testbalken. Abbildung 5: Der grüne JUnit-Testbalken Damit haben wir alle Phasen der TDD ausgeführt (siehe Abbildung 3), und ein Testgetriebene Entwicklungszyklus erfolgreich abgeschlossen. Aber natürlich sind wir noch nicht mit der Entwicklung der Programmlogik fertig. Daher als nächster Schritt, wird die Entwicklung der Logik angetrieben. Wobei dieses Wechselspiel zwischen den Tests und dem Programmcode weiter geführt wird, bis alle Anforderungen des Systems erfüllt sind ein guter Softwaredesign geschaffen ist das meiste Code mit Tests gesichert ist

14 3.4 Vorteile und Nachteile von TDD Vorteile von TDD Die Testgetriebene Entwicklung bringt viele Vorteile mit sich. In diesem Unterkapitel werden die wichtigsten davon zusammengefasst und beschrieben: Kein Code geht in die Produktion, ohne die zugehörigen Tests Die Codeabdeckung der Tests ist sehr hoch, dadurch ist die Software weniger fehleranfällig, und damit steigt die Qualität der Software. Durch die große Codeabdeckung der Tests ist bei einer Kodeänderung die Chance größer, Fehler zu entdecken. Während der Entwicklung kriegen die Entwickler durch die erfolgreichen Tests die Sicherheit, dass sie alle Anforderungen richtig umgesetzt haben. Die Entwicklung findet in kleinen stabilen Fortschritte statt Die TDD führt zu einem guten Softwaredesign Die Klassen werden möglichst entkoppelt und unabhängig von einander implementiert Alle Tests sind automatisiert Tests können häufig und jeder Zeit ausgeführt werden Nachteile von TDD Keine Code geht in die Produktion, ohne die zugehörigen Tests dieser Punkt wurde eben als Vorteil gesehen, aber das kann man von einer anderen Seite sehen, wenn man den großen Aufwand bedenkt, der bei der Wartung einer großen Menge von Test-Suites entsteht. Die Erfüllung der Tests mit kleinen Implementierungsschritten ist nicht immer möglich, zum Beispiel wenn andere Objekte oder Methoden noch fehlen

15 3.5 Tools zur Unterstüzung bei TDD In der modernen Software Entwicklung sind Hilfsmittel wie Editoren, Compiler oder Debugger nicht mehr wegzudenken geworden. Bei der Komplexität und der großen Anzahl an Zeilen Code der Software Produkten sind solche Werkzeuge unverzichtbar. Auch bei der Test-getriebene Entwicklung werden solche Werkzeuge eingesetzt. In diesem Kapitel werden vier Tools näher beschrieben xunit Mit xunit werden alle Unit Testing Frameworks bezeichnet. Sie basieren alle auf das erste entwickelte unit test Framework sunit, die für die Programmiersprache SamllTalk entwickelt wurde. Die Hauptaufgabe von einem Unit Test Framework ist die Bereitstellung von Bibliotheken, die die Entwickler unterstützen, unit Test zu schreiben, die auszuführen, und die Test Ergebnisse zusammenzufassen. Alle xunit Frameworks sind sehr ähnlich aufgebaut, daher wenn man eine kennt, ist es leicht einen anderen zu nutzen. In der Java Welt sind JUnit und TestNG am bekanntesten. Bei der Entwicklung von JUnit war Kent Beck beteiligt, der sunit entwickelt hat. JUnit wird in Kapitel 4 näher vorgestellt TDD Akzeptanztest Anders als in der Unit Test Phase ist die Unterstützung in der Akzeptanz Test Phase von Tools noch sehr ausbaufähig. Außerdem ist die Test-Automatisierung in der Abnahme Phase noch nicht so verbreitet wie bei der Entwicklungsphase mit xunit Frameworks. Denn ein Test zu automatisieren, der eine Komplette Funktionalität des Systems abdeckt ist natürlich komplexer als eine einzelne Methode zu testen. Das ist meistens aufgrund der Abhängigkeit und der Inhomogenität der anderen mitwirkenden Komponenten im gesamten System. Das bekannteste Tool ist Fit (Framework for integrated Testing). Es bietet die Möglichkeit, Tests durch einfache Tabellen zu schreiben. Damit können auch nicht technische Stakeholders wie Kunden oder Projekt Manager die Tests selbst definieren. Die Tabellen enthalten die Testszenarien mit den zugehörigen Test Parameter und die Erwarteten Ergebnisse. Jede Tabelle wird durch ein so genannte fixture als Test interpretiert, ausgeführt und die Testergebnisse ausgegeben. Diese fixture werden durch die Entwickler zur Verfügung gestellt. Die Testszenarien bzw. fixture können schon bei der Diskussion und Analyse der Anforderungen mit den Auftragsgebern geschrieben werden

16 3.5.3 Continous Build Die Software Entwicklung findet meistens in einem Team mit mehreren Entwicklern und Tester und auch oft in geografisch getrennten Orte. Dabei werden die Quellcode und Test Code in so genannten Repositories mit Hilfe eines Versionsverwaltung-Systems gehalten. Der entstandene Kode gehört natürlich dem ganzen Team, und kann von allen Team-Mitgliedern geändert werden. Damit die Integration der einzelnen Änderungen in dem gesamten System erfolgreich stattfinden kann, wird ein so genanntes Continous-Build-System eingesetzt. Das Continous-Build-System übernimmt die Aufgabe, den kompletten Quellcode zu kompilieren und alle automatisierten Tests zu starten, so bald eine Änderung im Source Repository eingecheckt wurde. Dadurch sparen sich die Team-Mitglieder Zeit, und können nur ein Teil der Tests lokal bei sich ausführen, bevor sie ihre Änderungen hochladen, und lassen das Continous-Build-System alle Tests, sowohl die Unit Tests als auch die Integrations-Tests ausführen. Nach jedem Lauf kriegen dann die Team-Mitglieder ein Feedback (per zum Beispiel) ob alles erfolgreich durchgelaufen ist oder nicht. Als Ergebnis eines Laufes kann eine ausführbare Software Module zusammengepackt und zur Verfügung gestellt werden. Die meist verwendeten Continous Build Systemen sind zu nennen Jenkins (jenkins-ci.org) und Criuse Control (cruisecontrol.sourceforge.net). Die beiden Tools sind open Source Code Coverage Die Code Coverage Tools messen, wie hoch die Abdeckung des Source-Kodes durch automatisierten Tests ist. Dabei wird aufgezählt wie viele Zeilen, Anweisungen, Abzweigungen und Bedienungen mit Tests durchgelaufen sind. In der Test-getriebene Entwicklung wird im idealen Fall die 100 % Abdeckung erreicht, weil ja kein Kode ohne Tests existieren könnte. In der Praxis aber ist es sehr schwierig das zu erreichen. Man sollte das am besten auch gar nicht als Ziel setzten, denn man schreibt in TDD Kode, damit die Tests durchlaufen, und nicht um die 100 % Code Coverage zu erreichen. Aber man sollte schon um die 100 % bleiben, auch wenn eine höhere Test-Abdeckung keine bessere und Fehler- freie Software bedeutet. Es gibt viele Code Coverage Tools auf dem Markt, und viele davon sind Open Source. Meistens auch schon in der Entwicklungsumgebung integriert, wie zum Beispiel in Eclipse oder IntelliJ. In der Java Welt beispielweise gibt es Cobertura ( und EMMA (

17 3.6 Konzepte und Patterns für TDD Test Auswahl Strategien Der erste Schritt, den man bei der Entwicklung mit der Test-getriebene Entwicklung machen muss, ist einen Test zu schreiben. Die Frage stellt sich hier mit welchem Test soll man anfangen? Um diese Frage zu beantworten werden in diesem Kapitel ein paar Strategien vorgestellt, die bei der Auswahl der Tests helfen können: Komponenten-Rahmen Tests versus Komponenten-Logik Tests: Komponenten-Rahmen Tests ist damit gemeint, dass man erst mal anfängt, die Umgebung der Komponente zu testen und zu implementieren. Dabei wird die Funktionalität und die Logik außer Acht gelassen. Und erst wenn die Komponenten-Umgebung getestet und funktioniert, wird die Logik und die Algorithmen implementiert. Bei der entgegneten Strategie Komponenten-Logik Tests werden zuerst die Algorithmen bis ins die Details getestet und implementiert. Die Architektur wird nicht berücksichtigt, erst wenn die Business Logik funktional ist, werden die Komponenten drum herum implementiert Bekannte versus unbekannte Terrain Die zweite Auswahl Strategie unterscheidet zwischen den zu dieser Zeitpunkt schon bekannten Bereichen des Software-Moduls und den noch nicht bekannten. Die bekannten Module sind sicherlich leichter und sicherer zu testen und zu implementieren. Das ist eine gute Strategie vor allem am Anfang der Entwicklung. Denn man kommt schneller voran und gewinnt die Sicherheit und Zuversicht Gültige Klassen Tests versus ungültige Klassen Test Hier werden entweder die erwarteten funktionalen Pfade als erstes getestet und implementiert, oder die unerwarteten. Die erwarteten Szenarien, auch gültige Klassen genannt, sind die normalen Anwendungsfälle, wo keine Fehler oder Fehlverhalten auftreten. Im Gegenteil, bei den ungültigen Klassen werden die Pfade mit Tests abdeckt, wo Fehler oder Ausnahmen stattfinden, beispielsweise aufgrund einer fremden Software-Modul oder fehlerhaften Input. In diesem Kapitel wurde die Frage behandelt, wie man den nächsten Test auswählt. Als nächstes stellt sich die Frage, wie man bei der Implementierung vorgehen kann. Das wird in dem folgenden Abschnitt beschrieben

18 3.6.2 Implementierungsstrategien Im Vorherigen Kapitel wurden einige Strategien gezeigt, wie man Tests schreiben könnte. In diesem Abschnitt werden einige Strategien beschrieben, wie man die geschriebenen Tests zum Laufen bringen könnte Funktionalität Simulieren Die erste und leichteste Variante ist die Funktionalität vom Source Kode so zu simulieren, so dass die Tests erfolgreich durchlaufen. Das heißt. es wird kein funktionalen Kode implementiert, stattdessen zum Beispiel werden nur hart Kodierte Rückgabe Werte geschrieben. Denn man möchte so schnell wie möglich, die Tests grün laufen sehen Triangulation Bei dieser Technik werden so viele Testfälle geschrieben, so dass die Implementierungslogik eingegrenzt wird. Mit jedem zusätzlichen Testfall wird die Logik erweitert, und das wird solange wiederholt bis das Algorithmus alle Gegebenheiten abdeckt, inklusive Fehlerbehandlung Klare Implementierung Klare Implementierung bedeutet dass man nicht lange über die optimale Implementierung nachdenkt und forscht, sondern die einfache Lösung wird implementiert. Damit man schneller die Tests zum Laufen bringen kann, und schneller Fortschritte im TDD Zyklus erzielen kann. Die Nachbesserung des Quellcodes kann am Ende in der Refactoring Phase gemacht werden Weitere TDD Richtlinien Hier noch ein paar weitere Best practice Richtlinien, die man bei der Test-getriebene Entwicklung sehr nützlich sein können Kleinere aber sichere Schritte Als Entwickler neigt man dazu, große Implementierungsschritte machen zu wollen. Dadurch könnten sowohl der Testcode als auch der Quellcode für eine einzelne Aufgabe sehr groß und unüberschaubar werden. Daher es ist besser, wenn die großen Aufgaben in einzelnen kleinen Aufgaben aufgeteilt werden. Dadurch kann man den Überblick behalten, um evtl. schneller Änderungen an den Tests oder an der Logik durchführen zu können

19 Refactoring nicht überspringen Die Umgestaltung des Quelltextes ist eine sehr wichtige Phase in der Test-getriebene Entwicklung und darf am besten niemals übersprungen werden. Denn es kann schnell passieren, dass man bei TDD in der Falle gerät, nur zwischen Test und Code blind hin und her schaltet. Das führt zu schlechtes Software Design oder viele redundanten Code. Durch eine Refactoring Phase dazwischen würde man das verhindern Schnell zu grün Der vorherige Punkt spricht trotzdem nicht dagegen, so schnell wie möglich, Code zu implementieren, um die Tests grün zu kriegen. Danach, also in der Refactoring-Phase, kann man zurück, um den Quelltext besser zu strukturieren und evtl. Duplikaten Code zu entfernen TDD Patterns Test Isolierung Wie in allen Methodiken der Testautomatisierung, ist die Tests Isolierung in der TDD auch ein sehr wichtiger Aspekt. Die einzelnen Tests sollen unabhängig voneinander sein. Das heißt, die Ergebnisse eines Tests sollen auf keiner Art und Weise die anderen Tests beeinflussen. Ein solche Fehlimplementierung ist zum Beispiel die Basis Test Daten in der Datenbank so zu verändern, dass bei der Ausführung der folgenden Tests die Datenbank nicht in dem erwarteten Zustand zu finden ist. Auch beim Fehlschlagen eines Tests soll weiter sichergestellt werden, dass die Testumgebung in einem sauberen Zustand hinter gelassen wird, und so mit die Ausführung der anderen Tests nicht verhindert wird Asserts zuerst Asserts 1 zuerst, bedeutet dass man beim Schreiben der Tests erst mal mit der Prüfung der erwarteten Werte anfängt. Hier ein Beispiel, um das zu verdeutlichen: Folgender Test soll die Anzahl der Kunden aus der Datenbank prüfen. Nehmen wir an, die erwartete Anzahl soll 10 Kunden sein. Also schreiben wir: testcountcustomers() {... assertequals(10, result.getint( count )); 1 Assert ist eine Klasse die eine xunit Framework zur Verfügung stellt, um die erwarteten Werte mit dern aktuellen zu vergleichen

20 Das Ergebnis soll aus der Datenbank kommen. Dann schreiben wir: testcountcustomers() {... ResulSet result = query.executequery(select COUNT(*) as count from customer); assertequals(10, result.getint( count )); Bevor wir ein SQL Abfrage schicken, muss eine Verbindung zu der Datenbank hergestellt werden, also wird der Test damit ergänzt: testcountcustomers() { Class.forName( com.mysql.jdbc.driver ); Connection con = Driver.getConnection( jdbc:mysql:// :3306/database? user=dbuser&password=secret ); Statement query = con.createstatement(); ResulSet result = query.executequery( SELECT COUNT(*) as count from customer ); result.next(); assertequals(10, result.getint( count )); Und so ist der Test komplett implementiert Test Daten In der Test-getriebene Entwicklung sind die Test-Daten ein sehr wichtiger Punkt. Denn mit welchen Daten man testet, hängt von den Anforderungen ab, und gleichzeitig haben die Test- Daten einen Einfluss auf die Implementierung und oder auf das Design. Die Folgenden Kriterien definieren die Test-Daten: Werte der Daten: Anzahl der Daten Verschiedene Datensätze Reale Daten

21 4 Testen mit JUnit 4.1 Download und Installation JUnit ist einfach zu installieren und zu benutzen. Nach wenigen Schritten kann man JUnit schon einsetzten: 1. Download von JUnit Package am besten von der JUnit offiziellen Seite 2. JUnit Package irgendwo im Datei System entpacken 3. Die im Package enthaltene Jar-Archive JUnit.jar im Java Class Pfad (definiert durch die Umgebungsvariable CLASSPATH) setzen Um sicherzustellen, dass die JUnit erfolgreich installiert wurde, kann man die mit dem Framework mitgelieferten Testes ausführen. java -classpath junit.jar;. junit.textui.testrunner junit.tests.alltests Time: OK (91 tests) In der Ausgabe zeigt jeder Punkt auf einen erfolgreich durchgelaufenen Test. Außerdem zeigt die Ausgabe die Anzahl der ausgeführten Tests, und die Zeit, die dafür verbraut wurde

22 4.2 JUnit-Klassendiagramm In diesem Kapitel werden die wichtigsten Klassen der JUnit Framework beschrieben. Die Abbildung 6 stellt die Struktur als Klassendiagramm dieser Klassen dar. Die einzelnen Klassen werden danach kurz erläutert. Abbildung 6: JUnit-Klassendiagramm TestCase: erbt von der JUnitTestCase Klasse. Sie enthält eine oder mehrere Tests, die durch testxxx Methoden repräsentiert werden. Also die TestCase Klasse definiert damit eine Umgebung, die für die Ausführung einen oder mehreren Tests angewendet wird. Die TestCase Klasse wird hauptsächlich benutzt, um Tests zu gruppieren, die gemeinsame Eigenschaften haben. TestSuite: definiert eine Sammlung von TestCases, die wiederum andere TestSuites enthalten können. die TestSuite und TestCase sind nach dem Entwurfmuster Kompositum

23 implementiert. Wobei Test ist die Komponente, TestSuite der Kompositum, und TestCase ist der Blatt. BaseTestRunner: ist die Benutzerschnittstelle zum Starten der TestCases bzw. TestSuites. JUnit bietet mehrere Test Starter, die alle von BaseTestRunner erben: junit.testui.testrunner: basiert auf die Eingabe Konsole junit.swingui.testrunner: basiert auf eine Swing Benutzerschnittstelle. (Abbildung 7) Abbildung 7: Java Swing basiertes Test-Runner junit.awtui.testrunner: basiert auf AWT Benutzerschnittstelle. (Abbildung 8)

24 Abbildung 8: Java AWT basiertes Test-Runner Assert: stellt eine Sammlung von Methoden zur Verfügung, um eine Soll-Ist-Vergleich durchzuführen. Wenn der Vergleich nicht erfolgreich ist, werfen die Methoden eine AssertionFailedError Exception mit einer Fehlermeldung, die den Methoden übergeben werden kann. TestResult: sammelt alle in den Tests aufgetretenen Fehler Test: ein Test-Objekt kann ausgeführt werden, dabei wird ihm ein TestResult-Objekt übergeben TestListener: horcht auf die Ereignisse, die während eines Tests auftreten, zum Beispiel auf Start oder Ende des Tests, Fehler etc

25 4.3 TestCase-Beispiel In diesem Abschnitt wird anhand eines einfachen Beispiels (aus [LKP08]) demonstriert, wie man mit JUnit testet. Natürlich dabei werden nicht alle JUnit Aspekte vorgestellt, aber die wichtigsten davon. import static org.junit.assert.*; import org.junit.*; import java.io.*; public class TestConsoleLogger { private static final String EOL = System.getProperty("line.separator"); private ConsoleLogger logger; private PrintStream originalsysout, originalsyserr; private ByteArrayOutputStream sysout, public void createfixture() { logger = new ConsoleLogger(); originalsysout = System.out; originalsyserr = System.err; sysout = new ByteArrayOutputStream(); syserr = new ByteArrayOutputStream(); System.setOut(new PrintStream(sysOut)); System.setErr(new public void resetstandardstreams() { System.setOut(originalSysOut); public void infolevelgoestosysout() throws Exception { logger.info("msg"); streamshouldcontain("[info] msg" + EOL, = 100) public void errorlevelgoestosyserr() throws Exception { logger.error("houston..."); streamshouldcontain("[error] Houston..."+ EOL, syserr.tostring()); private void streamshouldcontain(string expected,string actual) { assertequals("wrong stream content.",expected, actual);

26 Hier wird die Assert Klasse inkludiert, um assertxxx Methoden zu benutzen. Aus dem Namen der Klasse sollte man erkennen, dass es um einen Test handelt. Zum Beispiel mit dem Präfix Test dann der Name der Klasse, die getestet werden soll. Die Instanzvariablen, die gemeinsam in allen Tests gebraucht werden. Die annotierten Methoden werden vor jeder Test-Methode ausgeführt. Damit wird der Test jedes Mal in einem bestimmten Zustand gebracht. Die annotierten Methoden werden nach jeder Test-Methode ausgeführt. Damit wird der Test jedes Mal in einem bestimmten Zustand zurückgebracht. Alle annotierten Methoden werden als Test von JUnit 4 TestRunner betrachtet. Test-Methoden können beliebige Exception rauswerfen, JUnit wird sie abfangen Mit JUnit kann man Performanz-Tests schreiben. Mit dem Ausdruck (timeout = 100) bestimmt man die maximale Ausführungsdauer des Tests, wenn diese Zeit überschritten wird, schlägt der Test fehl. Man kann beliebig viele Hilfe-Methoden schreiben

27 4.4 TestSuite-Beipsiel Eine Test Suite bietet die Möglichkeit, mehrere Testfälle in einer Klasse zusammenzufassen. Dadurch kann man die Testfälle nach einer selbst definierten Struktur vereinen, und dadurch bestimmte Testfälle gemeinsam ausführen. JUnit stellt diese Möglichkeit auf einfacher Weise zur Verfügung. Folgende Klasse zeigt ein Beispiel einer Test Suite: Package mypackage; import org.junit.runner.runwith; import MyClassTest.class, MyClassTest.class, MyClassTest.class ) public class AllTests { Wenn eine Klasse mit RunWith annotiert wird, oder von einer Klasse erbt, die mit RunWith annotiert ist, ruft JUnit die referenzierte Klasse, um die Tests auszuführen. Mit Suite als Ausführer (Runner) kann eine Reihe von Tests von mehreren Test- Klassen gestartet werden Die Testklasssen die zu dieser TestSuite gehören. Die Test Suite Klasse

28 4.5 JUnit mit Eclipse Bei vielen Entwicklungsumgebungssyteme wie zum Beispiel IntelliJ, Netbeans, JBuilder und Eclipse ist JUnit integriert, und steht ohne weiteres bereit zum Einsatz. In diesem Abschnitt wird nur die Integration von JUnit in Eclipse beschrieben, aus dem einfachen Grund, dass eclipse die bekannteste Open Source Java IDE ist. JUnit wird durch das eclipse-plugin org.eclipse.jdt.junit geliefert. Und ermöglicht das starten von Tests und anschauen der Testsergebnisse direkt in der IDE. Schon beim Schreiben neuer JUnit Testfälle hilft das Plugin neue TestCase oder TestSuite Klassen zu erstellen. Einfach auf den Source Package gehen, wo der TestCase erstellt werden soll. Dann new JUnit Test Case (siehe Abbildung 9). Abbildung 9: Neuen Testfall in Eclipse anlegen (1) Anschließend erscheint ein Fenster (Abbildung 10), wo man folgende Eingaben machen kann: JUnit Version, die man einsetzen möchte. Hier zum Beispiel JUnit3 und JUnit4. (Wenn man die JUnit3 Version wählt, setzt eclipse automatisch junit.framework.testcase als Oberklasse im Superclass Feld) Name der TestCase

29 Methoden-Kopf wie zum Beispiel setup() oder teardown() können mitgeneriert werden Klasse, die man testen möchte. Abbildung 10: Neuen Testfall in Eclipse anlegen (2) Wenn man auf Next drückt, öffnet sich ein zweites Fenster (Abbildung 11), wo man wählen kann, die Methoden der Klasse, die getestet werde soll

30 Abbildung 11:Neuen Testfall in Eclipse anlegen (3) Mit Hilfe dieser Assistent kriegt man am Ende eine Test Klasse, oder besser ausgedrückt die Struktur einer Test Klasse, mit allen JUnit-Methoden, die man für den diesen TestCase braucht und allen Methoden der Klasse, die man testen möchte. Folgender Code zeigt ein Beispiel einer Test Klasse, die mit eclipse generiert wurde. Wie man im Beispiel sieht wurden alle Test Methoden mit der Methode fail( not yet implemented ) vorgesehen, um die Test ausfallen zu lassen. So kann der Entwickler den Überblick behalten, welche Test schon implementiert wurden und welche noch nicht

31 import static org.junit.assert.*; import org.junit.after; import org.junit.afterclass; import org.junit.before; import org.junit.beforeclass; import org.junit.test; public class StackTest public static void setupbeforeclass() throws Exception public static void teardownafterclass() throws Exception public void setup() throws Exception public void teardown() throws Exception public void teststack() { fail("not yet public void testpush() { fail("not yet public void testpop() { fail("not yet public void testtop() { fail("not yet public void testisempty() { fail("not yet public void testisfull() { fail("not yet public void testempty() { fail("not yet implemented");

32 Außerdem stellt das Plugin ein JUnit Test-Runner mit einer grafischen Oberfläche zur Verfügung. Abbildung 13 stellt das JUnit Test-Runner Ansicht dar. Diese Ansicht zeigt den Fortschritt der Ausführung der Tests, und am Ende einen Testsbericht mit der Anzahl der erfolgreichen und erfolglosen Tests, und ebenfalls die Fehlerprotokollierung. Abbildung 12: JUnit Test Runner in Eclipse

33 4.6 JUnit Erweiterungen DBUnit DbUnit ist eine JUnit-Extension, die Datenbank-getriebene Projekte adressiert. DbUnit übernimmt sowohl das Datenbank-spezifische Testfixture als auch die Evaluierung des Datenbankzustandes nach der Ausführung der zu testenden Operationen. Zusätzlich bietet DbUnit die Möglichkeit Tabellen komplett oder teilweise zu exportieren oder zu importieren, DbUnit ist im Internet unter zu finden. HTTPUnit HTTPUnit ist eine Java Framework zum Testen von Web-Applikationen. HTTPUnit emuliert das Verhalten eines Web-Browsers, einschließlich der Übermittlung eines Formulars, JavaScript, einfache HTTP-Authentifizierung, Cookies und automatischer Weiterleitung. HTTPUnit kann die zurückgegebenen Seiten in verschiedenen Formen untersuchen, z. B. Text, XML-DOM, Formulars, Tabellen oder Links. Die HTTPUnit Framework wird mit der ServeletUnit Bibliothek geliefert, die für das Testen von Servlet-Applikationen eingesetzt werden kann, ohne ein Servelet-Container zu brauchen. Durch die Kombination von HTTPUnit mit JUnit, wird ziemlich einfach Tests zu schreiben, die Funktionalität einer Website oder einer Web-Applikation zu prüfen. Auch HTTPUnit ist ein Open Source Projekt ( Cactus Cactus ist ein einfaches Test-Framework für Unit-Test-Server-seitigen Java Applikationen, z.b. zum Testen von Servlets, EJBs, Tag libs und JSPs. Die Absicht von Cactus ist es, den Aufwand für das Schreiben von Tests für den Server-seitigen Code zu senken. Es baut auf JUnit auf, und erweitert sie. Cactus setzt eine in-container-strategie ein. Was bedeutet, dass die Prüfungen im Inneren des Servlet bzw. EJB-Containers ausgeführt werden. Daher werden keine Mock-Objeckte für die Container gebraucht. Cactus ist ebenfalls open-source und wird von der Apache Software Foundation im Jakarta- Projekt entwickelt. Weiter zu Cactus kann man auf der offiziellen Seite finden

34 EasyMock EasyMock ist eine Bibliothek, die eine einfache Möglichkeit bietet, Mock-Objekte für Java Unit-Tests einer bestimmten Schnittstelle zu verwenden. Mit EasyMock werden die Mock- Objekte dynamisch erzeugt. Das Mock-Objekt simuliert das Verhalten des ersetzten Objektes, außerdem kann man überprüfen, ob der Mock-Objekt sich genauso verhalten hat, wie es vorgesehen war. EasyMock ist eine open-source framework. Weitere Informationen sind unter zu finden

35 5 Zusammenfassung Unit Tests sind in der modernen Softwareentwicklung eine feste Bestandteil des Prozesses geworden. In der Java Unfeld hat sich die JUnit Framework als die Standart Basis für die Entwicklertests etabliert. Und das aus verschiedenen Gründen. Wie wir gesehen haben, JUnit ist leicht zu installieren und einzusetzen. Vor allem durch die Integration von JUnit in allen Java-Entwicklungsumgebungen. Als Beispiel wurde die Integration von JUnit in Eclipse demonstriert. Außerdem werden die JUnit Tests in Java kodiert, was das Schreiben von Tests leicht macht. Zum anderen können die Tests mit Hilfe der TestRunner-Tools einfach und bequem ausgeführt werden, und die Testergebnisse analysiert werden. Durch JUnit hat man ein sehr hilfreiches Werkzeug in der Hand, und damit ist eine gute Basis geschaffen, um das Testgetriebene Entwicklungsmodell erfolgreicher zu betreiben. Es ist sicherlich sehr aufwändig nach dem TDD-Modell zu entwickeln und es fordert viel Disziplin, aber durch diese kleinen und vielen kurzen Test-Code-Refactoring Zyklen hat man in jeder Zeit einen sauberen und funktionierenden Kode. Was automatisch zu einer besseren Qualität der gesamten Software führt

36 Literatur [FWT06] [KBT02] [DAT03] [JLA05] [VMJ04] [LKP08] Frank Westphal: Testgetriebene Entwicklung mit JUnit & FIT dpunkt.verlag 2006 Kent Beck: Test-Driven Development by Example Addison-Wesley 2002 David Astels: Test-Driven Development: A Practical Guide Prentice Hall PTR 2003 Jeff Langr: Agile Java Crafting Code with Test-Driven Development Prentice Hall PTR 2005 Vincent Massol mit Ted Husted: JUnit in Action Manning 2004 Lassa Koskela: Practical TDD and Acceptance TDD for Java Developpers Manning

37 Abbildungsverzeichnis Abbildung 1: Testphase in Wasserfall-Model und Inkrementelle-Modell...5 Abbildung 2: Testphase in V-Modell...6 Abbildung 3: Phasen der Testgetriebene Entwicklung...10 Abbildung 4: Der rote JUnit-Testbalken...13 Abbildung 5: Der grüne JUnit-Testbalken...14 Abbildung 6: JUnit-Klassendiagramm...23 Abbildung 7: Java Swing basiertes Test-Runner...24 Abbildung 8: Java AWT basiertes Test-Runner...25 Abbildung 9: Neuen Testfall in Eclipse anlegen (1)...29 Abbildung 10: Neuen Testfall in Eclipse anlegen (2)...30 Abbildung 11:Neuen Testfall in Eclipse anlegen (3)...31 Abbildung 12: JUnit Test Runner in Eclipse