Test-Driven Development

Transkript

1 Test-Driven Development Seminar "Aktuelle Themen der Informatik" Ausarbeitung von Adrian Schlobies, CN8 1

2 Inhaltsverzeichnis 1 Einleitung Probleme üblicher Methoden Vorgehensweise Implikationen für Entwickler Organisches Feedback Eigene Tests Schnelle IDE Stimmiges Design Implikationen für Tests Geschwindigkeit Atomaritätsprinzip Aussagekräftige Daten Zielorientiertes Testen Traditionelle Tests Testmethoden Black Box Testing White Box Testing Grey Box Testing Werkzeuge Java Testframework Building / Scripting IDE Java SDK Beispiel Fazit Quellen

3 1 Einleitung Im heutigen sehr schnellen Umfeld der Softwareentwicklung muss oft programmiert werden, ohne die genauen Anforderungen des Kunden an das fertige Produkt wirklich zu kennen. Selbst wenn die Anforderungen einigermaßen bekannt sind, ändern sie sich doch häufig genug, dass der Prozess der Softwareentwicklung ständig im Fluss ist. Deswegen ist Softwaredesign kein Prozess, der zu einem bestimmten Zeitpunkt abgeschlossen ist, da das Design oft über den ganzen Entwicklungsprozess angepasst und verändert werden muss. Dadurch ist Softwareentwicklung zu einem fast schon als organisch zu bezeichnenden Prozess geworden. Es wird inkrementell in möglichst passenden Schritten vorgegangen, um sich langsam aber sicher an das heranzutasten, was der Kunde letztendlich als Ergebnis erwartet. Dieses Vorgehen bringt aber auch gewisse Nachteile mit sich. Durch ständige Erweiterung und Modifikation vorhandenen Sourcecodes läuft man Gefahr, dass sich mit jedem Schritt die Qualität des Codes verschlechtert. Es können sich Fehler einschleichen und der Code verkommt zu einer nicht mehr zu wartenden Flickwerk. Eine mögliche Lösung dieses Problems ist das so genannte Test-Driven Development. Hierbei beginnt man das schreiben von neuem Code damit, zunächst einmal einen Test für diesen Code zu schreiben, und erst wenn dieser wie erwartet fehlschlägt schreibt man Code, der diesen Test dann erfolgreich besteht. Da man immer nur genau soviel Code schreiben sollte, wie der Test verlangt, entsteht so in kleinen Schritten Code, der immer auch sofort getestet ist. Die Frage die sich hier natürlich stellt, ist wie man etwas testen kann, was noch garnicht existiert. Hierzu lässt sich sagen, das man schließlich auch nichts programmieren kann, wenn man nicht weiß, ob es denn erforderlich ist oder nicht. Dadurch, das man die Tests zuerst schreibt, stellt man sicher, das man auch wirklich das programmiert, was notwendig ist, und nicht irgendetwas, was man gerne möchte, was aber nicht erforderlich ist. 3

4 2 Probleme üblicher Methoden Bedient man sich nicht agiler Methoden der Softwareentwicklung wie dem Test-Driven Development, geht man meist nach dem Schema vor, zuerst die Software zu schreiben und hinterher, wenn diese in den Augen des Entwicklers "fertig" ist, die Tests zu schreiben und durchzuführen. Dadurch ergeben sich allerdings mehrere Probleme. Das Hauptproblem bei dieser Vorgehensweise ist die Tatsache, dass diese Tests am Ende meistens unter sehr großem Zeitdruck durchgeführt werden, da die Software ja eigentlich fertig ist und ausgeliefert werden soll. So kommt es dann dazu, dass diese Tests eher nachlässig durchgeführt werden. Außerdem stellt sich am Ende der Entwicklung häufig heraus, dass der erzeugte Code nicht wirklich im Hinblick auf eine leichte Testbarkeit geschrieben wurde, und es schwierig bis unmöglich ist, dafür Tests zu entwickeln, bzw. Fehler darin zu suchen und zu verbessern. Für den Fall, das der Code doch einigermaßen getestet werden kann, lauert dann aber noch ein weiteres Problem: Nämlich wenn der Entwickler des Codes diesen auch selber testen soll. Dieser kennt nämlich inhärente Schwächen des von ihm geschriebenen Codes, und testet im Pechfall absichtlich oder auch unabsichtlich um diese Fehler herum, so dass diese niemals auffallen, bis die Software von Anwendern produktiv eingesetzt wird. Diese werden dann nicht mehr darauf bedacht sein, Zustände zu vermeiden, in denen sich das Programm nicht so verhält wie es erwartet wird. 3 Vorgehensweise Die Vorgehensweise im Test-Driven Development wurde von Kent Beck, dem Begründer des Extreme Programming, wie folgt zusammengefasst: Make a test. Make it run. Then make it right. Mit diesen drei einfachen Sätzen ist das Test-Driven Development eigentlich auch schon komplett beschrieben. Um den Prozess auch erfolgreich durchführen zu können, gibt es noch zwei Richtlinien, die ebenfalls beachtet werden sollen. Sie lauten 1. Nur neuen Code schreiben, wenn ein Test fehlschlägt 2. Redundanzen eliminieren Die erste Richtlinie ist gleichzeitig auch der Grundgedanke des Test-Driven Development. Dieser besteht darin, immer zuerst einen Test zu schreiben, der nicht erfolgreich ist, und sich dann Gedanken darüber zu machen, was für Code geschrieben werden muss, um diesen Test erfolgreich abzuschließen. Die zweite Richtlinie sollte auch befolgt werden, wenn man sich keiner agilen Methoden bedient, da Redundanzen im Code ein Nachteil sind, die Wartung des Codes erschweren und eine Quelle für Fehler darstellen. So ist beispielsweise oft nicht klar ist, welche der redundanten aber vielleicht nicht völlig identischen Methoden aufgerufen wird. 4

5 4 Implikationen für Entwickler Hier werden Vor- und Nachteile für den direkt durch Test-Driven Development betroffenen Entwickler beschrieben, da die Verwendung dieser Entwicklungsmethode einige Regeln, Vorteile und Einschränkungen mit sich bringt, die beachtet werden sollten, bzw. beachtet werden müssen. 4.1 Organisches Feedback Wie bereits in der Einleitung gewinnt der Softwareentwicklungsprozess durch Verwendung von Test- Driven Development eine organische Komponente, da man der Software bei der Entwicklung beim Wachsen zusehen kann, da lediglich kleine Schritte gemacht werden. Auch hat man als Entwickler ein sehr direktes Feedback, da jeder Schritt durch einen Test abgedeckt wird, und so also im Extremfall jede einzelne Zeile Code sofort durch einen Test validiert oder als nicht korrekt bewertet wird. Im Anwendungsfall wird man natürlich nicht für jede Zeile Code einen Test schreiben, sondern zumindest Teile von Methoden oder ganze Methoden schreiben und diese dann auf ihre Funktionalität hin testen. 4.2 Eigene Tests Ein weiterer Vorteil bei der Verwendung dieser Entwicklungsmethode ist die Tatsache, dass der Entwickler sich seine Tests selbst schreiben muss. Dies ist insofern von Vorteil, dass man nicht noch zusätzlich eine Testabteilung beschäftigen muss, die auf Anfrage Tests durchführt. Ein weiterer Vorteil ist hier natürlich auch, dass der Entwickler eigentlich am besten wissen sollte, welche Tests er durchführen sollte, um am Ende möglichst fehlerfreie Software abliefern zu können. Allerdings wäre es auch gar nicht möglich, jemand anderen als den betroffenen Entwickler die Tests schreiben zu lassen da er sonst dutzende Male am Tag darauf warten müsste, das jemand aus der Testabteilung ihm den nächsten Test schreibt, um einige Zeilen Code zu testen. Sozusagen "auf Vorrat" mehr Code zu schreiben als ihn der aktuell fehlschlagende Test benötigt ist etwas, was beim Test- Driven Development streng verboten ist, da dadurch Code entstehen würde, der durch keinen Test abgesichert ist und wahrscheinlich auch nie durch einen Test überprüft werden wird, also eine große Fehlerquelle darstellt. 4.3 Schnelle IDE Wie später noch erläutert werden wird, ist es bei der Entwicklung mit Test-Driven Development sehr wichtig, eine Entwicklungsumgebung zu verwenden, die gewisse Funktionen erstens überhaupt mitbringt und diese zweitens auch schnell durchführen kann. Die Rede ist hier von Refaktorierung von Code und der Möglichkeit, UnitTests schnell durchführen zu können. Dies ist deswegen so wichtig, da viel Zeit darauf verwendet wird, geschriebenen Code so früh wie möglich und so häufig wie möglich zu refaktorieren. Auch UnitTests werden andauernd durchgeführt, hier muss also auch darauf geachtet werden keine endlosen Wartezeiten zu erzeugen. 5

6 4.4 Stimmiges Design Test-Driven Development leistet viel, kann dem Entwickler aber nicht die Arbeit abnehmen, vor dem Beginn der Programmierung ein stimmiges Design zu entwerfen. Dieses Design wird aller Wahrscheinlichkeit nach zwar im Laufe des Entwicklungsprozesses noch verändert, muss aber dennoch vorhanden sein. Hier zeigt sich nämlich eines der Probleme von Test-Driven Development. Oftmals benötigt man für die Erfüllung eines Tests Programmteile, die noch gar nicht geschrieben sind, und ein möglichst modulares Design mit klar definierten Schnittstellen ist hier von Vorteil. Ist nämlich klar definiert, wo Abhängigkeiten bestehen, kann man diese sehr viel einfacher auflösen, und muss nicht damit beginnen, einen Methodenrumpf nach dem anderen zu schreiben, um einen einzelnen Test zu bestehen, der viele halbfertige nicht komplett getestete Methoden nach sich ziehen würde. 5 Implikationen für Tests Nachdem wir beleuchtet haben, wie sich Test-Driven Development auf den Entwickler auswirkt, hier nun eine Übersicht über die Auswirkungen, die diese Methode auf die zu implementierenden Tests hat. 5.1 Geschwindigkeit Wie bereits erwähnt ist es sehr wichtig, dass Tests schnell durchgeführt werden können. Dies hängt natürlich nur zu einem Teil von der Entwicklungsumgebung ab. Zu einem großen Teil ist dafür natürlich auch der Test selbst verantwortlich. Ein Test sollte darauf optimiert werden, wirklich nur das zu testen, worauf es im Moment gerade wirklich ankommt, und sollte des Weiteren dies auch noch mit so wenig Aufwand wie möglich tun. Bei anderen Entwicklungsmethoden ist es durchaus üblich, über Nacht diverse Tests über die Codebase laufen zu lassen, die durchaus auch länger dauern dürfen, da die Ergebnisse sowieso erst am nächsten Tag interessant sein werden. Beim Test-Driven Development kann man sich diese Zeit nicht nehmen. 5.2 Atomaritätsprinzip Hier geht es wie aus dem Gebiet der Datenbanken bekannt sein dürfte darum, dass Tests nicht voneinander abhängen dürfen. Es muss also möglich sein, die Reihenfolge in der die Tests ablaufen zu verändern und es sollte auch möglich sein, einen Test, der etwas überprüft, was bekanntermaßen oder sogar absichtlich nicht funktioniert wegzulassen, ohne dass die anderen Tests davon in Mitleidenschaft gezogen werden. Diese Regel ergibt sich eigentlich automatisch daraus, dass ein Test sowieso nur jeweils die neuesten Zeilen Code überprüfen soll, und demnach mit anderen Tests, die sich um anderen Code kümmern gar nichts zu tun haben kann. 6

7 5.3 Aussagekräftige Daten Hier geht es darum, dass der Entwickler möglichst mit Daten testen sollte, die auch später in der Produktion eingesetzt werden. Wenn die Möglichkeit besteht, ist es sogar am besten mit einer Kopie von Produktionsdaten zu arbeiten, da dann die Wahrscheinlichkeit am größten ist, das alle möglichen Werte abgedeckt werden. Der Hintergrund ist hier folgender: Wenn man beim Testen lediglich einige ausgedachte, womöglich noch besonders einfache Werte benutzt wie z.b. 0, 1, 2 kann das leicht dazu führen, dass Fehler die erst auftreten, wenn man sich im Zahlenbereich größer 1000 aufhält niemals entdeckt werden. Bei der Verwendung von Produktionsdaten sinkt dieses Risiko, da man hier einen repräsentativen Querschnitt der möglichen Eingangsdaten zum Testen heranziehen kann. Hierbei sollte man aber nicht außer Acht lassen, dass man andererseits auch wieder nicht zu viele Daten in einem Test verwenden sollte, da dieses den Test nur langsamer macht, was wie bereits erläutert keinesfalls wünschenswert ist. 5.4 Zielorientiertes Testen Diese Vorgabe ist relativ einfach erklärt. Tests sollten immer überprüfen, ob ein neu geschriebenes Stück Code einen Schritt in die richtige Richtung darstellt. Stellt man beim Schreiben eines Tests fest, dass das damit zu testende Stück Code einen nicht weiter bringt, muss man den Test überdenken, da man nicht um des Testens willen Tests schreiben sollte. 5.5 Traditionelle Tests Nicht vergessen darf man allerdings, dass Test-Driven Development kein Ersatz für alle anderen traditionellen Testmethoden ist. So ist ein User acceptance testing nach wie vor sehr wichtig, da die beste Software nichts bringt, wenn der Kunde diese nicht abnimmt, weil er nicht mit dem Ergebnis zufrieden ist. Auch bei der Systemintegration gibt es durchzuführende Arbeiten und Tests, die allerdings nicht mit Test-Driven Development erledigt werden können. So sollte man sich diese Methode also als sehr hilfreiches Werkzeug, aber kaum als das Allheilmittel in der Softwareentwicklung vorstellen. 7

8 6 Testmethoden In diesem Teil der Ausarbeitung beschäftigen wir uns mit drei verschiedenen Testmethoden, um ein besseres Verständnis davon zu bekommen, warum Test-Driven Development so erfolgreich funktioniert. 6.1 Black Box Testing Hierbei handelt es sich um eine Testmethode, die eine eigene Testabteilung benötigt, da der Entwickler des Codes diesen Test nicht durchführen kann. Wie der Name schon vermuten lässt, testet man die Software ohne Kenntnisse über ihre innere Funktionsweise zu haben. Für die Erstellung von Testcases wird lediglich die Spezifikation der Software herangezogen, die Einzelheiten der Implementierung bleiben aussen vor. Die Vorteile von Black Box Testing liegen darin, das hier das Gesamtsystem einem Test unterzogen wird, und nicht die einzelnen Komponenten betrachtet werden. Weiterhin ist es hier unmöglich, um Fehler herumzutesten, da eventuelle dem Entwickler bekannte Schwachstellen dem Testteam unbekannt bleiben, und deswegen darauf keine Rücksicht genommen wird. Ein Nachteil dieser Testmethode ist beispielsweise der höhere Aufwand für eine Testabteilung. 6.2 White Box Testing Hier handelt es sich um eine Testmethode, die quasi das Gegenteil von Black Box Testing ist. Bei dieser Art zu Testen kennt der Testende den Sourcecode und prüft auch an diesem. Hierbei geht es also mehr um ein Testen der Einzelkomponenten, und weniger darum, herauszufinden, ob die Spezifikation eingehalten wurde. Die Vorteile des Black Box Testing sind hier die Nachteile und umgekehrt, so dass sich diese beiden Tests recht gut ergänzen, bzw. sich verbinden lassen, wie man im nächsten Beispiel sehen wird. 6.3 Grey Box Testing Dieser Test fasst Black und White Box Testing zusammen, um so die jeweiligen Nachteile der beiden Tests dadurch zu kompensieren, dass ihre Vorteile miteinander kombiniert werden. Die Gemeinsamkeit mit Black Box Testing ist, dass der Tester anfänglich nichts über den Code weiss, da dieser erst noch geschrieben werden muss, so wird vermieden, dass um Fehler herum getestet werden kann. Die Gemeinsamkeit dieses Tests mit dem White Box Testing ist die Tatsache, das hier der Tester und der Entwickler ein und die selbe Preson sind, d.h. man schreibt seine Test selbst. Auch hier muss nochmals betont werden, das dieser Test lediglich ein Teil der durchgeführten Tests sein darf, da auch hier nicht alle Fehler entdeckt werden können. 8

9 7 Werkzeuge In diesem Abschnitt soll erklärt werden, welche Werkzeuge der Entwickler benötigt, wenn er sich des Test-Driven Developments bedienen will. Als Beispiel wurde die Softwareentwicklung unter Java gewählt. 7.1 Java Testframework Hier bietet sich JUnit an, ein Framework zur automatisierten Durchführung von UnitTests. Eine Unit kann hierbei eine Klasse oder eine Methode sein, die mittels eines ebenfalls in Java geschriebenen Tests auf ihre Funktionalität hin überprüft werden kann. 7.2 Building / Scripting Hier kommt meist Ant zum Einsatz. Dabei handelt es sich um eine ebenfalls in Java geschriebene Skriptumgebung, um den build-prozess zu automatisieren. Ant wird auch gerne als "make für Java" bezeichnet, da es hier ähnliche Aufgaben übernimmt wie das bekannte make für C. Das JUnit Framework kann hier ebenfalls integriert werden, so dass mittels der durch den Benutzer erweiterbaren Ant-Syntax auch JUnit-Tests automatisiert werden können. 7.3 IDE Bei der Java-Programmierung kommt sehr oft die ebenfalls in Java geschriebene Eclipse- Entwicklungsumgebung zum Einsatz. Wie bereits beschrieben ist es notwendig, dass die IDE Refaktorierung unterstützt, da diese sehr häufig zum Einsatz kommt. Ein weiterer Vorteil ist die Möglichkeit, das JUnit-Testframework ebenfalls zu integrieren, so dass alle notwendigen Aufgaben innerhalb einer Umgebung durchgeführt werden können. 7.4 Java SDK Natürlich ist für die Entwicklung von Java-Software auch ein SDK notwendig, dieses hat aber keinen großen Einfluss auf Test-Driven Development, und wird demnach auch hier nicht weiter beschrieben. 9

10 8 Beispiel Hier wird nun anhand einer Funktionalität, die den Geschmack von Äpfeln angibt, demonstriert, wie Test-Driven Development eigentlich funktioniert. Zunächst einmal schreibt man einen Testfall. public class AppleTest extends TestCase { public void testtaste() { assertequals("golden Delicious should taste sweet", "SWEET", apple.gettaste()); Hiermit wird eine Testmethode namens testtaste() geschaffen, und festgelegt, das ein Apfelobjekt süß schmecken soll. Nun muss noch eine Apfelinstanz angelegt werden: public class AppleTest extens TestCase { public void testtaste() { Apple apple = new Apple("GOLDEN DELICIOUS"); assertequals("golden Delicious should taste sweet", "SWEET", apple.gettaste()); Zu diesem Zeitpunkt existiert noch keine Apfelklasse, so dass der Testfall noch nicht kompiliert werden kann, da zumindest die Klasse vorhanden sein muss, bevor etwas getestet werden kann. public class Apple { private String type; public Apple(String type) { this.type = type; public String gettaste() { return ""; Nun kann der Testfall kompiliert werden, und wird auch gleich mit einer Fehlermeldung quittiert. Die erhaltene Fehlermeldung junit.framework.comparisonfailure zeigt an, das die Methode gettaste offensichtlich noch nicht so funktioniert, wie vom Testfall verlangt. Also muss die Apfelklasse noch verfeinert werden. 10

11 public class Apple { private String type; public Apple(String type) { this.type = type; public String gettaste() { if (type == "GOLDEN DELICIOUS") return "SWEET"; else return "SOUR"; Nun wird der Testfall erfolgreich ausgeführt, und wir haben in kleinen Schritten das erreicht, was wir uns bei der Implementierung des Testfalls vorgenommen haben. Bei näherer Betrachtung der Apfelklasse fällt allerdings auf, das die Apfelsorte hardcodiert ist. Verwendet man die Apfelklasse muss man also wissen, was für Apfelsorten existieren, und den richtig geschriebenen String an den Konstruktor übergeben. Jetzt ist es Zeit für einen weiteren Schritt von Test-Driven Development, dem Refaktorieren. public class AppleTest extends TestCase { public void testtaste() { Apple apple = New GoldenDelicious(); assertequals("golden Delicious should taste sweet", "SWEET", apple.gettaste()); Hier wird nun keine Apfelinstanz sondern eine Golden Delicious-Instanz erzeugt. Apple wird nicht länger als Klasse, sondern als Interface verwendet. Die Apfelklasse wird also wie folgt angepasst: Public interface Apple { private String gettaste(); Zum Schluss wird noch die Klasse GoldenDelicious implementiert: Public class Golden Delicious implements Apple { private static final String TASTE = "SWEET"; public String gettaste() { return TASTE; Spätestens jetzt muss der Test ein weiteres mal ausgeführt werden, um zu sehen, ob durch die diversen durgeführten Veränderungen das Programm noch wie gewünscht funktioniert. Wie erwartet ist dies der Fall, und man kann sich dem nächsten Entwicklungsschritt zuwenden. 11

12 9 Fazit Abschließend lässt sich sagen, das Test-Driven Development ein sehr gut mit anderen agilen Entwicklungsmethoden kombinierbares Werkzeug ist, mit dessen Hilfe man einen Schritt näher an das Ziel gelangt, fehlerfreien Code zu schreiben. Der grösste Nachteil von Test-Driven Development lieg sicher darin, das es teilweise etwas langsam erscheint. Die Größe der Schritte zwischen zwei Tests kann zwar frei gewählt werden, aber es wird in der Literatur trotzdem immer wieder betont, dass diese möglichst klein sein sollten. Dadurch entsteht natürlich das Bild einer sehr langsamen Vorgehensweise. Dieser Nachteil ist allerdings auch gleichzeitig wieder als Vorteil zu sehen, da bei strikter Einhaltung dieser kleinen Schritte fast jede Zeile Code einen eigenen Testfall besitzt, so dass sich eine sehr gute Testabdeckung realisieren lässt. 10 Quellen Titelthema Testen, Java Spektrum 6/2005 Thomas Hammell, Test-Driven Development: A J2EE Example, Apress 2004 Scott W. Ambler, Introduction to Test Driven Development, Uwe Vigenschow, Objektorientiertes Testen und Tesautomatisierung inder Praxis, dpunkt.verlag 2005 William E. Perry, Software testen, mitp-verlag