Humboldt-Universität zu Berlin

Transkript

1 Humboldt-Universität zu Berlin Institut für Informatik Einführung von Unit Tests in das bestehende C++ Softwaresystem SUMO Diplomarbeit Matthias Heppner 27. Dezember 2009 Gutachter: Prof. Dr. Klaus Bothe Humboldt-Universität zu Berlin Dr. Michael Behrisch Deutsches Zentrum für Luft und Raumfahrt

2

3 INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Aufbau der Arbeit Verwandte Arbeiten SUMO Einführung in SUMO Testverfahren in SUMO Unit Testing Warum Unit Tests schreiben? Unit Test Frameworks Testcase Assert Methoden Testfixture Testrunner Testsuite Testresult Test-Driven Development Refactoring Testkonzepte für Unit Tests Mock Objekte Testen von privaten Methoden Testen von Exceptions Ein Assert pro Testmethode Unit Test als Regressionstest Auswirkungen auf den Programmierstil Weitere Konzepte Unit Test Frameworks für C Warum existieren für C++ so viele Unit Test Frameworks? Übersicht der bekanntesten Frameworks Testkriterien Unit Test Frameworks CxxTest Boost Test Library TUT Unit i

4 INHALTSVERZEICHNIS CppUnit Google Test Fazit: Unit Test Framework Auswahl Auswahl der zu testenden Klassen Analyse der Klassenstruktur Analyse der Ausführungshäufigkeit Testfallspezifikation Funktionales Testen Äquivalenzklassentest Grenzwerttest Zufallstest Strukturelles Testen Anweisungsüberdeckung Zweigüberdeckung Pfadüberdeckung Boundary-interior Pfadtest Bedingungsüberdeckung C++ Code Coverage Tools GCov Automatische Testfallgenerierung Realisierung von Unit Tests Anlegen der Testklassenstruktur Erstellung von Unit Tests Testfälle erstellen und umsetzen Testen von Exception Testen mit Testfixtures Verwendung von Mock Objekten Refactoring Daily Build Auswertung Fazit über die Auswahl des Test Frameworks Auswertung der Einführung von Unit Tests in SUMO Zusammenfassung und Ausblick Zusammenfassung Ausblick A GoogleTest mit Visual Studio unter Windows verwenden 72 ii

5 INHALTSVERZEICHNIS B GoogleTest mit gcc unter Unix verwenden 72 C GProf 73 D Auflistung der Fehler 75 Literaturverzeichnis 76 iii

6

7 1 Einleitung 1.1 Motivation Das Testen von Software nimmt eine wichtige Position in der Softwareentwicklung ein. Dies gilt auch für das Softwaresystem SUMO[12] (Simulation of Urban MObility), welches deshalb um Unit Tests erweitert werden soll. SUMO ist ein Programm zur Simulation des Verkehrsflusses, dessen Komplexität und Umfang stetig zunimmt. Die Entwicklung begann im Jahr 2001, bis heute ist das Projekt mit allen Bibliotheken auf etwa 400 Klassen angewachsen und beinhaltet rund Codezeilen. Weil es sich bei SUMO um ein Open Source Projekt handelt, gibt es ein ständig wechselndes Entwicklungsteam, wodurch sich einige zusätzliche Probleme ergeben. So kommt es einerseits zu häufigen Programmänderungen und anderseits ist nicht jeder Programmierer mit allen Teilen von SUMO vertraut. Auf diese Weise treten schneller Programmierfehler auf als bei einem festen Entwicklungsteam. In SUMO existieren zwar schon ausführliche Akzeptanztests, die das System als Ganzes testen, aber das Einführen von Unit Tests auf der untersten Ebene erhöht zusätzlich die Sicherheit des Systems. Jeder Entwickler kann die bestehenden Unit Tests leicht erweitern, während das Anpassen der Akzeptanztests schwieriger ist. Die Unit Tests haben im Vergleich zu anderen Testverfahren einige Vorteile. Wird nach dem Prinzip des Test Driven Developments[1] entwickelt, werden zunächst Tests geschrieben, bevor der Programmcode entwickelt wird. Mithilfe von Unit Tests lassen sich somit schon während des Programmierens Fehler vermeiden. Falls Fehler auftreten und ein Unit Test fehlschlägt, lassen sich die möglichen Fehlerursachen schneller auffinden und ein zeitintensives Debuggen verhindern. 1.2 Zielsetzung Der Schwerpunkt dieser Diplomarbeit liegt in der Integration eines Unit Test Frameworks in das bestehende Softwaresystem SUMO. Hierfür muss als Erstes ein geeignetes Unit Test Framework aus einer Vielzahl von Frameworks ausgewählt werden. Um die Unit Test Frameworks miteinander vergleichen zu können, werden verschiedene Unit Testing Konzepte vorgestellt. Mithilfe des ausgewähltem Frameworks werden dann Unit Tests implementiert. Damit der Nutzen der Tests möglichst groß ist, muss zuvor entschieden werden, welche Klassen zuerst getestet werden sollen. Darüber hinaus ist vor allem die Wahl der Testfälle von Bedeutung, um eine Klasse vollständig zu testen. Es muss überprüft werden, ob sich das ausgewählte Framework in der Praxis bewährt hat. In diesem Zusammenhang wird der Frage nachgegangen, ob sich der Aufwand des nachträglichen Hinzufügens von Unit Tests in existierenden Programmcode lohnt. 1

8 1.3 Aufbau der Arbeit 1.3 Aufbau der Arbeit Die Arbeit ist im Wesentlichen in zwei Teile gegliedert. Der erste Teil beschäftigt sich mit der Auswahl eines Unit Test Frameworks, während es im zweiten Teil darum geht Konzepte zu erarbeiten, die für die zielgerichtete Umsetzung von Unit Tests in SUMO benötigt werden. Bevor ein Unit Test Framework ausgewählt werden kann, werden alle wichtigen Begriffe und Konzepte des Unit Testing beschrieben. Dazu gehört neben dem inneren Aufbau eines Frameworks auch die Beschreibung wie Unit Testing Konzepte in der Praxis angewandt werden. Im weiteren Verlauf der Arbeit wird ein C++ Unit Test Framework für SUMO ausgewählt. Für die Auswahl des Frameworks werden die sechs bekanntesten Tools analysiert, indem verschiedener Kriterien bewertet werden sowie ein kleines Beispielprogramm ihre Anwendung testet. Nachdem die Frameworks abschließend bewertet worden sind, wird eines von ihnen ausgewählt, mit dem die ersten Unit Tests entstehen können. Zuvor muss jedoch geklärt werden, welche Klassen getestet werden sollen und anhand welcher Kriterien die Testfälle auszuwählen sind. Für die Auswahl der Testklassen werden zwei Ansätze verfolgt. Einerseits wird die Struktur des Programms untersucht, d.h. es wird der Frage nachgegangen, welche Klassenabhängigkeiten untereinander bestehen. So ist es sinnvoll möglichst Klassen zu testen, die wenige bis keine Abhängigkeiten besitzen und sich erst danach Klassen mit mehreren Abhängigkeiten zuzuwenden. Andererseits wird die Ausführungshäufigkeit untersucht, die mithilfe eines Profilers berechnet wird, während SUMO eine Simulation durchläuft. Methoden und Klassen, die besonders häufig verwendet werden, sind entsprechend wichtig für SU- MO und sollten demnach ausführlich getestet sein. Im nächsten Schritt müssen geeignete Testfälle ausgewählt werden. Hierbei ist es wichtig, die Testfälle so zu wählen, dass eine Klasse vollständig überprüft wird. In diesem Zusammenhang werden sowohl funktionsorientierte wie auch strukturorientierte Tests näher betrachtet. Eine wichtige Rolle bei der Auswahl der funktionsorientierten Testfälle haben die Grenzwerttests, weil bei den Grenzwerten häufig Fehler auftreten. Um zu überprüfen, ob die Qualität der Tests ausreichend ist, werden verschiedene Überdeckungsgrade vorgestellt und ihre Vor- und Nachteile beschrieben. Darüber hinaus soll ein Tool ausgewählt werden, mit dem sich Überdeckungsgrade messen lassen und welches für SUMO geeignet ist. Im Anschluss werden dann einige Unit Test realisiert, die bisherigen Konzepte angewandt und an Beispielen demonstriert, bevor die Auswertung folgt. In der Auswertung wird darauf eingegangen, ob das ausgewählte Framework den Anforderungen gerecht geworden ist und es wird geklärt, ob der Aufwand des Einführens von Unit Tests in ein bestehendes Softwaresystem den Nutzen der Unit Tests rechtfertigt. 2

9 1.4 Verwandte Arbeiten 1.4 Verwandte Arbeiten Im Bereich des Unit Testing existiert eine Vielzahl von vorhandener Literatur. Allerdings gibt es speziell zu der Thematik, welche die Einführung von Unit Tests in bestehende Software beschreibt, nur sehr wenig verfügbare Literatur. In den verschiedenen Publikationen wird meistens nur der Zusammenhang von Unit Tests mit dem Test Driven Development (TDD) ausgeführt. Kent Beck [2] empfiehlt sogar, dass keine Unit Tests für bestehenden Code geschrieben werden sollten, weil der Zeitaufwand dafür zu groß ist. Dennoch lässt sich das Konzept der Unit Tests auf bestehende Software anwenden, auch wenn dabei das Vorgehen im Vergleich zum TDD leicht verändert ist. Johannes Link [3] gibt einen kurze Übersicht zu dieser Problematik, geht allerdings vor allem auf die Auswirkungen auf das Entwicklerteam und die zunächst veränderten Entwicklungsphasen ein. Er beschriebt kurz, wann es sinnvoll ist, neue Unit Tests zu schreiben und verweist darauf, dass es unnötig ist, alle Klasse vollständig zu testen, um eine ausreichende Basis an Tests zu schaffen. In der Diplomarbeit von Adrian Kuhn mit dem Thema Software-Qualitätssicherung für das PUA-Tool werden auch Unit Tests in das Softwaresystem PUA eingeführt. Allerdings liegt hier der Schwerpunkt mehr auf dem vollständige Testen der Software und der Beseitigung vorhandener Fehler. So wird weniger auf die Testfallbestimmung und der Problematik, in welchem Umfang und zu welchen Klassen Unit Tests sinnvoll sind, eingegangen. Auch entfällt in dieser Arbeit die Auswahl eines Test Frameworks, da das Programm in Java geschrieben ist und somit JUnit als Framework benutzt werden konnte. 3

10 2 SUMO 2.1 Einführung in SUMO SUMO (Simulation of Urban MObility) ist ein Open Source Projekt, welches am Institut für Verkehrssystemtechnik des DLR (Deutsches Zentrum für Luft- und Raumfahrt ev) entwickelt worden ist. Das Projekt entstand im Jahr 2001 und wird kontinuierlich weitergeführt, so dass bis heute mehr als 400 Klassen existieren, die rund Codezeilen beinhalten. Daneben sind auch eine große Anzahl von Dokumentationen entstanden, die SUMO von der Installation bis hin Benutzung beschreiben. Des weiteren wurden auch Publikationen veröffentlicht, die sich mit der Komplexität von Verkehrssimulationen befassen und die zeigen, dass es sich um ein aktuelles Forschungsgebiet handelt. Mithilfe von SUMO lassen sich komplexe Verkehrssimulationen durchführen, Straßennetze definieren und der Verkehrsfluss reproduzierbar analysieren. SUMO erlaubt die detailgenaue Modellierung des Straßenaufbaus und die Steuerung des Verkehrsdurchflusses, indem Fahrzeuge auf Routen durch das Straßennetz geschickt werden. Jedes Fahrzeug hat ein zugrundeliegendes Modell, so dass sich reale Situationen nachstellen lassen, wie beispielsweise ein Stau oder das Anfahren eines Fahrzeugs. So können ganze Stadtteile mit ihrem Verkehrsfluss nachgestellt werden. Für SUMO gibt es viele Anwendungsszenarien, die verdeutlichen, wie sich das Hinzufügen eines Fahrstreifens oder eine veränderte Ampelschaltung auf den Verkehr auswirken. In Abbildung 1 ist eine Beispielsimulation der Simulation-GUI (Graphical User Interface) von SUMO dargestellt. Bei der Entwicklung von SUMO wird besonders darauf geachtet, dass das Softwaresystem portabel bleibt. Alle verwendeten Programme müssen plattformunabhängig sein. So wird SUMO derzeit vor allem für Windows und Unix Plattformen entwickelt. Aus der Portabilität leitet sich auch eine wichtige Anforderung für das gesuchte Test Framework ab. In verschiedenen Projekten wurde SUMO bereits mit Erfolg verwendet. Ein Überblick über alle Projekte ist auf der Homepage von SUMO zu finden [12]. Darunter finden sich viele interessante Aufgabenstellungen, wie zum Beispiel die Vorhersage des Verkehrsaufkommens für den Weltjugendtag im Jahr 2005 oder für die FIFA Weltmeisterschaft Testverfahren in SUMO Bisher gibt es in SUMO eine Reihe von ausführlichen Akzeptanztests. Die Akzeptanztests werden mithilfe des Open Source Tools TextTest[13] durchgeführt, das die Ausgabe von SUMO mit einer vorher definierten Vergleichsdatei überprüft. Damit ist sichergestellt, dass sich SUMO nach einer Programmänderung weiterhin richtig 4

11 2.2 Testverfahren in SUMO Abbildung 1: Beispielsimulation einer Ampelkreuzung mit der Simulation-GUI verhält bzw. sich genauso verhält wie vor der Änderung. Allerdings birgt die Vergleichsdatei eine gewisse Fehlerquelle, da diese im Allgemeinen per Hand erstellt und überprüft wird. Im Fall von SUMO wurde die Vergleichsdatei aus der Ausgabe von SUMO generiert und enthält somit auch mögliche Programmfehler. Allerdings wird die Datei nochmal auf Fehler überprüft. Inzwischen existiert eine Vielzahl von Testszenarien für die Akzeptanztests, die SUMO ausführlich testen. Neben den Akzeptanztests existieren noch keine weiteren Testverfahren. Um das Programm trotzdem durch weitere mögliche Fehlerquellen abzusichern, ist das Einführen weiterer Testverfahren, wie dem Unit Testing, sinnvoll. 5

12 3 Unit Testing Dieses Kapitel gibt eine Einführung in den Themenkomplex des Unit Testing. Es wird dargestellt, warum das Schreiben von Unit Tests sinnvoll ist und warum das Konzept des Unit Testing angewandt werden sollte. Danach werden wichtige Begriffe sowie der prinzipielle Aufbau eines Unit Test Frameworks anhand von Beispielen erklärt. Für das Schreiben von Unit Tests werden verschiedene Konzepte benötigt, die vorgestellt, erläutert und in den weiteren Kapiteln angewandt werden. Darüber hinaus werden weitere Möglichkeiten für die Verwendung von Unit Tests, die in dieser Arbeit nur peripher behandelt werden können, am Ende des Kapitels vorgestellt. 3.1 Warum Unit Tests schreiben? Das Konzept hinter dem Unit Testing ist sehr einfach, so dass bereits das Schreiben eines Hello World Programms als Unit Test aufgefasst werden kann. Hierbei wird überprüft, ob die Programmiersprache korrekt installiert ist. Auch die Ausgabe von Variablen auf die Konsole mittels cout in C++ oder System.out.println in Java sind mit Unit Tests vergleichbar. Die ausgegebenen Werte werden mit denjenigen verglichen, die erwartet werden. Stimmen diese überein, ist der Test erfolgreich. Vielfach wird auch eine main Methode in einer Klasse implementiert, um diese zu testen. Dazu wird die Klasse erzeugt, verschiedene Methoden an dieser aufgerufen und die Ergebnisse zur Überprüfung wieder auf die Konsole ausgegeben. Die gerade aufgelisteten Beispiele von Testmöglichkeiten haben eine große Gemeinsamkeit, welche auch gleichzeitig ihr Nachteil ist. Nachdem eine Klasse oder eine Methode fertig gestellt ist, werden die Tests auskommentiert oder gelöscht, da sie nicht mit der eigentlichen Programmfunktionalität im Zusammenhang stehen. Die Ideen und die Zeit, die darin investiert wurden, gehen verloren. Viel besser wäre es, diese Ideen zu erhalten. Das Konzept des Unit Testing gibt dem ganzen einen Rahmen. Ohne großen Aufwand können die Tests aus den vorherigen Beispielen in eine weitere Klasse auslagert werden. In dieser werden alle Tests gesammelt und entsprechend strukturiert. Diese Klasse wird nicht wieder gelöscht und existiert parallel zur Klasse, welche sie testet. Alle enthaltenen Tests sind jederzeit aufrufbar und können somit das Verhalten wiederholbar überprüfen. Wenn Programmcode geändert wird, können die Tests sicherstellen, dass die vorherige Programmlogik immer noch funktioniert. Dies entspricht im Wesentlichen dem Grundkonzept des Unit Testing. Das Schreiben von Unit Tests ist somit wenig zeitaufwändig, effizient und vom hohen Nutzen. Langfristig entsteht durch Unit Testing auch ein besseres Design des Programmcodes, weil vorausschauend programmiert wird und erst nach dem Durchdenken der benötigte Funktionalität, diese implementiert wird. Sollten später Fehler auftreten, können die Fehlerstelle schneller lokalisiert werden und es wird weniger Zeit beim Debuggen verbracht. Daher ist es ratsam beim Erstellen von 6

13 3.2 Unit Test Frameworks neuem Code immer eine zugehörige Unit Test Klasse anzulegen. 3.2 Unit Test Frameworks Unit Test Frameworks sind Software Tools, die eine Grundfunktionalität bereitstellen, um Tests zu schreiben und auszuführen. Sie vereinheitlichen die Art wie Unit Tests aufgebaut sind und liefern aufbereitete Testergebnisse. So gut wie alle Unit Test Frameworks besitzen die gleichen Grundelemente. Dazu gehören der Testcase, die Testsuite, das Textfixture, der Testrunner, das Testresult und die Asserts. Wie diese Elemente zusammenhängen ist in Abbildung 2 (vgl. [7] S.31) zu sehen. Die Grundelemente werden in den nächsten Unterkapiteln vorgestellt, um zu verstehen, wie Unit Test Frameworks funktionieren. Test Assert Testfixture implementiert implementiert Testsuite führt aus werden hinzugefügt Testcase Testrunner sammelt Ergebnisse Testresult Abbildung 2: Klassen eines Unit Test Frameworks Der Aufbau in Abbildung 2 stammt im Wesentlichen aus dem Unit Test Framework JUnit[14], welches für Java entwickelt wurde. JUnit zählt zu dem ersten und bis heute wichtigstem Framework. Aufgrund seines Bekanntheitsgrades orientieren sich andere Frameworks an die Funktionalität von JUnit. Auch wenn Abweichungen bei dem Klassendiagramm festgestellt werden können oder der grundlegende Aufbau nicht immer identisch ist, finden sich die gleichen Grundelemente in jedem Framework wieder. Alle Beispiele, die in diesem Kapitel folgen, sind in einer Art C++ Pseudocode geschrieben und berücksichtigen keinen Framework spezifischen Programmcode. Weil der prinzipielle Aufbau bei allen Unit Test Frameworks identisch ist, lässt sich der Code auf die später vorgestellten Frameworks problemlos übertragen. 7

14 3.2 Unit Test Frameworks Testcase Die wichtigste Klasse in einem Unit Test Framework ist Testcase. Alle geschriebenen Testklassen werden von Testcase abgeleitet. Über Testcase wird bestimmt wie eine Testklasse und die einzelnen Test aufgebaut sein müssen. Einfache Tests können mithilfe von Testcase erstellt und ausgeführt werden, ohne zusätzliches Wissen über den Aufbau des Frameworks zu besitzen. Ein einfaches Beispiel sieht folgendermaßen aus: #i n c l u d e <Framework. h> #i n c l u d e <Framework Main Method. cpp> #i n c l u d e Quadrat. h void testumfang ( ) { Quadrat * quadrat = new Quadrat ( 2 ) ; a s s e r t E q u a l s ( ( 8, quadrat >getumfang ( ) ) ; Die Methode assertequals wird vom Framework ausgewertet. Eine Auflistung aller Assert-Methoden folgt im nächsten Abschnitt. Sobald ein Assert zu false ausgewertet wird, schlägt der Test fehl. Das Framework teilt dann mit, an welcher Stelle und warum der Test fehlgeschlagen ist. Wenn mehrere Tests in einer Klassen vorhanden sind, wird mit der Auswertung der anderen Tests fortgefahren. Alle Testmethoden sind voneinander unabhängig, so dass ein fehlgeschlagener Test keine anderen Test beeinflusst und die Reihenfolge der Ausführung der Tests keinen Unterschied in den Testergebnissen ausmacht Assert Methoden In jedem Framework wird eine Menge von Assert Methoden bereitgestellt. Die Auswahl ist meistens überschaubar und die Verwendung erfolgt intuitiv. Die wichtigsten Assert Methoden, die in allen Unit Test Frameworks vorhanden sind, werden in der folgenden Übersicht aufgelistet: 8 - asserttrue(boolean condition): Die Methode überprüft, ob die condition true ist. - assertfalse(boolean condition): Die Methode überprüft, ob die condition false ist. - assertequals(expected, actual): Die Methode überprüft, ob expected gleich actual ist. Sie sollte für verschiedene Typen gültig sein zum Beispiel Boolean, int oder String. - assertnull(object object): Die Methode überprüft, ob das Objekt gleich null ist.

15 3.2 Unit Test Frameworks - assertsame(object expected, Object actual): Die Methode überprüft, ob die Objekte gleich sind. - fail(): Der Test schlägt fehl. Mithilfe dieser wenigen Assert Methoden ist es möglich, ein Programm komplett zu testen. Um die Verwendung eines Frameworks noch einfacher zu gestalten, werden auch des öfteren weitere Assert Methoden zur Verfügung gestellt. Zum Beispiel eine Assert Methode, die direkt überprüft, ob Exceptions geworfen werden. Falls die Funktionalität eines Frameworks zu gering ist, können auch leicht eigene Assert Methoden gechrieben werden, die zum Beispiel zwei beliebige Objekte miteinander vergleichen: void a s s e r t E q u a l s ( Person * per1, Person * per2 ) { asserttrue ( strcmp ( per1 >getvorname ( ), per2 >getvorname ( ) ) && strcmp ( per1 >getnachname ( ), per2 >getnachname ( ) ) ) ; Testfixture Das Testfixture ist ein wichtiges Konzept der Unit Test Frameworks. Mithilfe eines Testfixtures wird ein definierter Zustand hergestellt. Dies kann das Laden einer Datenbank mit festgelegten Inhalt sein oder das Instanzieren eines Objektes. Das Konzept wird in Unit Test Frameworks durch eine Set-Up und eine Tear-Down Methode realisiert, die für jede Testklasse überschrieben werden können. Im Folgendem wird die Verwendung an einem Beispiel gezeigt. #i n c l u d e <Framework. h> #i n c l u d e <Framework Main Method. cpp> #i n c l u d e Quadrat. h private Quadrat * quadrat ; void setup ( ) { * quadrat = new Quadrat ( 2 ) ; void teardown ( ) { d e l e t e quadrat ; void testumfang ( ) { a s s e r t E q u a l s ( ( 8, quadrat >getumfang ( ) ) ; 9

16 3.2 Unit Test Frameworks void t e s t F l a e c h e ( ) { a s s e r t E q u a l s ( ( 4, quadrat >getflaeche ( ) ) ; Die Set-Up Methode erzeugt ein neues Objekt vom Typ Quadrat. Jeder Testmethode steht das Objekt aus der Set-Up Methode zur Verfügung. Die Set-Up Methode wird vor jedem Test aufgerufen und nachdem ein Test gelaufen ist, wird die Tear- Down Methode ausgeführt. In C++ empfiehlt es sich, in der Tear-Down Methode die Objekte wieder zu löschen, um den belegten Speicher freizugeben. Das Testfixture bietet einige Vorteile und sollte, wenn es sinnvoll ist, verwendet werden. In erster Linie reduziert es Codeduplikationen und macht dadurch die Testmethoden kürzer und verständlicher. Dennoch bleibt das Prinzip, dass alle Tests isoliert betrachtet werden können, erhalten. Auch wenn ein Test fehlschlägt, sichert das Testfixture, dass die Tear-Down Methode aufgerufen wird Testrunner Der Testrunner führt Tests aus und schreibt die Ergebnisse in das Testresult. Dabei erhält er als Argument eine Testklasse, die vom Typ Testcase oder Testsuite ist. Alle enthaltenen Testmethoden werden nacheinander ausgeführt. Die Frameworks erkennen auf unterschiedliche Weise die Testmethoden. In JUnit werden alle Methoden gesucht die mit test anfangen. Dies ist in Java mithilfe von Reflections einfach zu realisieren. Das Konzept der Reflections wird in C++ nicht unterstützt, darum ist es möglich, dass in C++ die Testmethoden nochmals einzeln registriert werden. Wie in spätereren Kapiteln beschrieben wird, gibt es aber auch C++ Frameworks, die automatisch Testmethoden erkennen. In vielen Frameworks existiert eine main Methode, die automatisch einen Testrunner initialisiert und startet. Vereinzelt kann es aber auch vorkommen, dass die main Methode noch programmiert werden muss. In beiden Fällen ist es möglich dem Testrunner mit verschiedenen Parametern aufzurufen. So kann über den Testrunner gesteuert werden, ob alle Testmethoden oder nur eine Teilmenge ausgeführt werden sollen oder in welchem Format das Testresult ausgegeben werden soll Testsuite Eine Testsuite wird benötigt, wenn mehrere Testklassen zusammengefasst werden sollen. Dem Testrunner kann neben einem Testcase auch eine Testsuite übergeben werden, so dass es möglich ist, mehrere Testklassen in einem Testlauf auszuführen. Über eine add Methode lassen sich neue Testklassen, welche das Interface Test implementieren, hinzufügen. Wie in Abbildung 2 dargestellt, sind dies Testcase und Testsuite. Auf diese Weise kann einer Testsuite wieder eine Testsuite hinzufügt wer- 10

17 3.3 Test-Driven Development den, so dass sich beliebige Hierarchien aus Testcases und Testsuites aufbauen lassen. Zusätzlich können aber auch nur einzelne Testmethoden aus einer Testklasse hinzufügt werden. Wie eine Testsuite aufgebaut werden kann, verdeutlicht folgender Programmcode. #i n c l u d e <Framework. h> #i n c l u d e <Framework Main Method. cpp> class GeometrischeFigurenTests : public TestSuite { public : Test s u i t e ( ) { TestSuite * s u i t e = new TestSuite ( ) ; s u i t e >addtest (new TestSuite ( QuadratTest ) ) ; s u i t e >addtest (new KreisTest ( testumfang ) ) ; return s u i t e ; Es ist hilfreich, wenn ein Unit Test Framework automatisch eine Testsuite aufbaut, die beispielsweise alle in einem Ordner befindlichen Testklassen enthält, so dass Arbeitsaufwand eingespart werden kann. Ebenso wird eine mögliche Fehlerquelle umgangen, weil das Hinzufügen einer neuen Testklasse zu einer Testsuite nicht mehr vergessen werden kann Testresult Das Objekt Testresult ist ein einfaches Objekt. Alle Ereignisse, die während des Ausführens der Tests auftreten, werden im Testresult gesammelt. Dazu zählen beispielsweise die Anzahl der erfolgreichen oder fehlgeschlagenen Tests. Schlägt ein Test fehl, muss sich zusätzlich der Fehler sowie die Stelle im Programmcode gemerkt werden. Das Testresult kann entsprechend aufbereitet werden, um es für den Nutzer übersichtlich darzustellen. So sind neben der einfachen Ausgabe auf der Konsole auch Ausgaben in XML oder HMTL denkbar. 3.3 Test-Driven Development Der Begriff des Unit Testing wurde vom Extreme Programming[2] geprägt. Einer der Mitbegründer und der bekannteste Vertreter des Extreme Programming ist Kent Beck. Er trug, durch seine Arbeit als Entwickler von JUnit[14], maßgeblich zur Entwicklung von Unit Testing bei. Die Grundidee des Extreme Programming ist es, anders als bei den klassischen Softwareentwicklungsmodellen, wie beispielsweise dem Wasserfallmodell, den Entwicklungsprozess in viele kleinere Phasen aufzuteilen. Dabei rückt die formale Spezifikation der Programmanforderungen in den Hintergrund. 11

18 3.3 Test-Driven Development Viele Anforderungen ergeben sich meistens erst während des Entwicklungsprozesses. Dabei wird besonderen Wert auf die Kommunikation mit dem Kunden gelegt. Schon in frühen Entwicklungsphasen werden erste Programmteile fertiggestellt und können mit dem Kunden besprochen werden. In jeder Entwicklungsphase wird erneut eine Rahmenplanung für die aktuelle Iteration festgelegt. Somit kann besonders flexibel auf geänderte Kundenwünsche reagiert werden und ein Projekt Stück für Stück zu einem fertigen Produkt entwickelt werden. Das Test-Driven Development[1] ist eine Ausprägung des Extreme Programming. Die Verwendung von Unit Test Frameworks wird noch stärker in den Entwicklungsprozess eingebunden. Im Test-Driven Development wird nach dem Prinzip des Test First Musters programmiert, d.h. es wird erst ein Test für eine Anforderung geschrieben und im Anschluss wird die entsprechende Anforderung implementiert. Jede Entwicklung von neuem Code ist in drei Phasen eingeteilt. 1 Es wird ein Test geschrieben, der die neuen Anforderungen genau spezifiziert oder einen Fehler darstellt. Dieser Test muss fehlschlagen. 2 Es wird neuer Code geschrieben, bis der Test erfolgreich durchlaufen wird, ebenso wie alle älteren Testfälle. Dabei soll der Code so einfach wie möglich sein. 3 Es wird ein Code Refactoring durchgeführt, welches sicherstellt, dass ein sauberes Design entsteht. Alle drei Phasen werden immer wieder durchlaufen, dabei werden nicht mehrere Tests auf einmal geschrieben, sondern das Programm anhand einzelner Tests sukzessive erweitert. Da der Code möglichst einfach programmiert werden soll, reicht es oft schon, wenn Methoden feste Werte zurückliefern, damit ein Test nicht fehlschlägt. Diese Vorgehensweise ist beabsichtigt. Vielfach wird erst ein weiterer Test die gewünschte Funktionalität komplett abbilden, so dass die Qualität der Tests auch die Funktionalität des Programms bestimmt. Sollte zu einem späterem Zeitpunkt ein Fehler im Programm auftauchen, muss zuerst ein Test geschrieben werden, der diesen Fehler nachstellt, bevor der eigentliche Fehler behoben werden sollte. Verschiedene Untersuchen (vgl. [5]) haben gezeigt, dass der zusätzliche Aufwand verschiedene Testverfahren in ein Projekt zu integrieren, zu deutlich weniger Fehlern und zu einer höheren Entdeckungsrate von Fehlern führt. Dies liegt bei den Unit Tests vor allem daran, dass der bereits geschriebene Testcode hilft keine Fehler in schon bestehenden Code einzubauen. Sobald getesteter Code verändert wird und dabei Fehler auftreten, werden diese sofort beim Ausführen der Tests entdeckt. Auch helfen die Unit Tests, die Fehlerursache schneller zu finden. Für die Anhänger des Test-Driven Development sind dies die entscheidenden Vorteile. 12

19 3.4 Refactoring 3.4 Refactoring Bei der Entwicklung nach dem Prinzip des Test-Driven Development s (TDD) werden viele kleinere Refactorings in den programmierten Klassen durchgeführt, somit ist die Anwendung von Refactorings eng mit dem TDD verbunden (vgl. [1], S.181ff). Während diese noch leicht durchzuführen sind, weil der Programmcode gerade erst entwickelt wurde, treten bei der Einführung von Unit Tests in ein bestehendes Softwaresystem einige Probleme auf. Die Software wurde nicht in erster Linie für die Testbarkeit durch Unit Tests entwickelt. Vielfach lassen sich Programmteile dadurch nicht testen. Somit ist meistens der einzige Weg, das Programm testbar zu machen, ein Refactoring durchzuführen. Dennoch liegt gerade hier das Problem. Martin Fowler[10] beschreibt, dass ein Refactoring nur durchführt werden sollte, wenn dieses durch Tests abgedeckt ist. Andersfalls kann es sehr schnell zu Bugs kommen, die erst mal unerkannt bleiben und später Probleme verursachen. Einfache Refactorings können selbstverständlich auch ohne Tests durchführt werden. Am einfachsten geht dies, wenn ein geeignetes Tool vorhanden ist, welches automatisch Refactorings durchführt und entsprechend alle Referenzen richtig ändert. Die Einführung von Unit Tests in SUMO trifft auf diese Problematik. Da die Klassen nicht durch Unit Test abgedeckt sind, sollte sehr genau überprüft werden, ob eine Klasse testbar gemacht werden sollte und im Zweifel lieber darauf verzichten. Allerdings ist SUMO sehr sauber programmiert und somit lassen sich viele Klassen testen, ohne ein Refactoring durchzuführen. 3.5 Testkonzepte für Unit Tests Mock Objekte Eine grundlegende Idee des Unit Testing ist es, dass jeder Test eine einzelne Funktionalität testet. Nicht immer kann die Funktionalität isoliert betrachtet werden. Dies liegt daran, dass viele Klassen andere Klassen verwenden, um die eigene Logik zu implementieren. Somit werden eventuell Abhängigkeiten zu sehr komplexen Klassen oder zu Klassen, die mit einer Datenbank oder einen Netzwerk verbunden sind, erstellt, die zu Problemen beim Schreiben der Unit Tests führen. Bei besonders komplexen Klassen können mögliche Seiteneffekte nicht mehr einfach isoliert werden oder es wird ungewollt die Funktionalität dieser Klasse getestet, die aber in eigenen Unit Tests überprüft werden sollte. Noch schwerwiegendere Probleme ergeben sich bei der Verwendung von Datenbanken. Die Datenbank muss sich vor jedem Test immer in einem konsistenten Zustand befinden, um die Testergebnisse reproduzierbar zu erzeugen. Somit ist die Verwendung der Produktivdatenbank nicht geeignet. Des Weiteren muss vor jedem Test die Datenbank komplett neu initialisiert werden. Dies kann, neben dem zusätzlichen Aufwand, auch zu deutlich langsameren Tests führen. Ferner treten auch Probleme auf, wenn sich das Programm mit ei- 13

20 3.5 Testkonzepte für Unit Tests nem Netzwerk verbindet. Es ist nicht sichergestellt, dass das Netzwerk immer eine Verbindung herstellen kann, ebenso kann es zu zeitlichen Verzögerungen kommen. Dadurch können Tests unkontrolliert fehlschlagen und sind nicht reproduzierbar. Bei allen diesen Problemen können Mock Objekte weiterhelfen. Ein Mock Objekt simuliert ein reales Objekt. In einem Test wird anstelle des realen Objektes das entsprechende Mock Objekt verwendet. Eine Mock Klasse kann auf zwei verschiedene Arten angelegt werden. Im ersten Fall erweitert die Mock Klasse die eigentliche Klasse und überschreibt Methoden. Im zweiten Fall implementiert die Mock Klasse ein Interface oder eine abstrakte Klasse. Voraussetzung dafür ist allerdings, dass die eigentliche Klasse auch dieses Interface implementiert. Die Implementierung der Mock Klasse wird dabei möglichst einfach gehalten und sollte kein Verhalten nachprogrammieren. Eine konkrete Umsetzung hat dann Methoden, die einen festgelegten Rückgabewert haben, unabhängig davon wie der Zustand des Objektes ist oder welche Übergabeparameter die Methoden bekommen haben. Im Folgenden wird beispielhaft die Verwendung eines Mock Objektes demonstriert (vgl. [7] S.42). Es wird die Klasse QuadrateDB getestet, deren Aufgabe es ist eine Verbindung zu einer Datenbank herzustellen und alle Quadrate auszulesen. class QuadrateDB { public : QuadrateDB ( DBConnection con ) : con ( con ) { vector <Quadrat> getquadrate ( ) { con. connect ; vector <Quadrat> quadrate = con. s e l e c t Q u a d r a t e ( ) ; con. d i s c o n n e c t ; return quadrate ; private : DBConnection con ; Dem Parameter des Konstruktors wird eine DBConnection übergeben. Dies ist eine abstrakte Klasse, welche folgendermaßen aufgebaut ist: class DBConnection { public : v i r t u a l void connect ( ) = 0 ; v i r t u a l void d i s c o n n e c t ( ) = 0 ; v i r t u a l vector <Quadrat> s e l e c t Q u a d r a t e ( ) = 0 ; 14 Es wird eine Instanz der Klasse DBConnection benötigt, um die Klasse Quadra-

21 3.5 Testkonzepte für Unit Tests tedb zu testen. Um das Problem, eine Datenbank zu initialisieren und diese mit Werten zu füllen, zu umgehen, wird eine Mock Klasse von DBConnection erstellt. Eine Beispielimplementierung ist im Folgenden angegeben. c l a s s MockDBConnection : DBConnection { public : void connect ( ) { connected = true ; void d i s c o n n e c t ( ) { d i s c o n n e c t e d = f a l s e ; vector <Quadrat> s e l e c t Q u a d r a t e ( ) { vector <Quadrat> quadrate ; return quadrate ; boolean v a l i d a t e ( ) { return connected && d i s c o n n e c t e d ; private : boolean connected = f a l s e ; boolean d i s c o n n e c t e d = f a l s e ; Die Methode selectquadrate greift auf keine Datenbank zu, sondern gibt eine leere Collection zurück. Um zu überprüfen, ob die Methoden connect und disconnect innerhalb der Methode getquadrate aufgerufen wurden, müssen entsprechende Werte gesetzt werden. Über die Methode validate lassen sich diese dann überprüfen. Für die Testklasse ergibt sich letztendlich folgende Implementation: #i n c l u d e <Framework. h> #i n c l u d e <Framework Main Method. cpp> #i n c l u d e Quadrat. h void testgetquadrate ( ) { MockDBConnection *mock = new MockDBConnection ( ) ; QuadratDB *db = new QuadratDB (*mock ) ; vector <Quadrat> quadrate = db >getquadrate ( ) ; a s s e r t E q u a l s ( 0, quadrate >s i z e ( ) ) ; asserttrue (mock >v a l i d a t e ( ) ) ; Die zusätzlich verwendetet Methode validate ist keinesfalls typisch für Mock Objekte, demonstriert aber die Möglichkeiten mit Mock Objekten zu arbeiten. Vielfach 15

22 3.5 Testkonzepte für Unit Tests werden einfach die vorhandenen Methoden überschrieben und möglichst einfach implementiert. In der Entwicklung nach dem Prinzip des TDD s ergibt sich noch eine weitere Verwendung von Mock Objekten. Da die Tests während der Entwicklung geschrieben werden, sind nicht immer alle verwendeten Klassen vollständig implementiert. Um trotzdem funktionierende Tests zu schreiben, können diese durch Mock Klassen ersetzt werden Testen von privaten Methoden Auf das Testen von privaten Methoden sollte möglichst verzichtet werden, weil private Methoden Implementierungsdetails einer Klasse beinhalten, die nicht nach außen hin sichtbar sein sollten. Dementsprechend gibt es keinen Grund einen Testfall für private Methoden zu erstellen. Allerdings ist dies nicht immer so einfach zu betrachten. So kann es durchaus vorkommen, dass komplexerer Code in eine private Methode ausgelagert wird und diese Methode besser isoliert getestet werden kann, als einen Umweg über eine public Methode machen zu müssen. Dies trifft vor allem dann zu, wenn eine Testabdeckung von 100% erreicht werden soll. Im Allgemeinen sollte das Design aber so gewählt werden, dass eine Klasse vollständig durch seine public Methoden getestet werden kann und private Methoden nicht getestet werden. Dennoch gibt es in den unterschiedlichen Programmiersprachen die Möglichkeit, auch private Methoden zu testen. Zwei Ansätze für die Programmiersprachen C++ und Java sollen kurz vorgestellt werden. In C++ besteht die Möglichkeit, die Testklasse als friend in der zu testenden Klasse zu deklarieren und damit Zugang zu den protected und privaten Methoden zu erhalten. Allerdings ist dieser Ansatz nicht empfehlenswert, da der Produktivcode geändert werden muss und die Testklasse davon abhängig wird. Somit sollte in C++ vollständig darauf verzichtet werden, private Methoden zu testen. Java besitzt einen anderen Mechanismus, um private Methoden zu testen. Mithilfe von Reflections kann auf die Methoden einer Klasse zugegriffen werden und sich dadurch Zugang zu den private Methoden verschafft werden. Der Vorteil dieses Ansatzes ist es, dass der Testcode unabhängig vom Produktivcode ist. Dennoch wird die Testmethode sehr unübersichtlich, da der Aufruf einer Methode per Reflection einige Zeilen Code benötigt. Deshalb sollte auch dieser Ansatz mit Bedacht eingesetzt werden Testen von Exceptions Die Fehlerbehandlung eines Programms sollte, genauso wie der andere Programmcode, auch getestet werden, um festzustellen, ob die richtige Exception geworfen wird und ob der Fehlertext stimmt. Das Abfangen der Fehler lässt sich in der Testmethode 16

23 3.5 Testkonzepte für Unit Tests mit einem try-catch-block bewerkstelligen und mithilfe des fail-asserts kann überprüft werden, ob der Fehler auch tatsächlich geworfen wird. Eine Beispielanwendung sieht folgendermaßen aus: #i n c l u d e <Framework. h> #i n c l u d e <Framework Main Method. cpp> #i n c l u d e Quadrat. h void testnegativesargument ( ) { try { new Quadrat ( 2); f a i l ( Es s o l l t e e i n e Exception geworfen werden. ) ; catch ( IllegalArgumentException e ) { a s s e r t E q u a l s ( S e i t e n l ä n g e i s t n egativ, e. getmessage ( ) ) ; Ein Assert pro Testmethode Es ist eine sinnvolle Regel, wenn beim Schreiben von Unit Tests jede Testmethode genau ein Assert verwendet, so dass jeder Test genau einen Testfall abdeckt. Werden mehrere Asserts benutzt, werden auch mehrere Aspekte des Programms getestet. Dieser Ansatz bringt viele Vorteile mit sich. Da immer nur ein Testfall ausgeführt wird, kann schon der Methodenname so gewählt werden, dass der Zweck des Tests sofort erkennbar ist. Auch bleiben die Tests dadurch kurz und übersichtlich. Ein weiterer großer Vorteil ist es, dass, falls ein Test fehlschlägt, alle anderen Tests noch ausgeführt werden, während bei der Verwendung von weiteren Asserts in einer Testmethode diese abhängig vom Framework nicht ausgeführt werden. Dennoch ist in der Praxis dieses Konzept zu restriktiv, da die Anzahl der Testmethoden dadurch sehr schnell ansteigt. Deshalb ist Verwendung mehrerer Asserts in einer Testmethode, wenn diese das gleiche Verhalten testen, durchaus sinnvoll. Die ursprüngliche Idee sollte aber immer eingehalten werden, d.h. die Testmethode sollte möglichst kurz sein und sich auf einen Testfall konzentrieren Unit Test als Regressionstest Ein Regressionstest ist das erneute Ausführen von bereits erfolgreich ausgeführten Tests. Mithilfe der Regressionstests wird sichergestellt, dass bestehender Programmcode durch Programmänderungen weiterhin fehlerfrei funktioniert (vgl. [4] S.192). Somit wird erreicht, dass die Qualität der getesteten Software erhalten bleibt und keine neuen Fehler oder Seiteneffekte auftreten. Deshalb müssen nach jeder Programmänderung alle vorhandenen Tests erneut ausgeführt werden. Unit Tests eig- 17

24 3.5 Testkonzepte für Unit Tests nen sich hervorragend, um als Regressionstest eingesetzt zu werden. Dies geschieht zum einen lokal auf dem Rechner eines Programmierers. Durch das Ausführen von Unit Tests sollte nach jeder Programmänderung sichergestellt werden, dass die zugehörigen Tests noch funktionieren. Damit werden die meisten Fehler sofort erkannt und können behoben werden, bevor eine Klasse für andere Programmierer freigegeben wird. Aus zeitlichen Gründen ist es zumeist nicht möglich, alle Testklassen eines Programms nach jeder Änderung auszuführen. Dies kann dazu führen, dass Fehler in anderen Programmteilen auftreten, ohne dass dies unmittelbar bemerkbar ist. Deshalb sollten alle Unit Tests täglich als Regressionstest ausgeführt werden. Dieser sollte automatisch ausgeführt werden und alle auftretenden Fehler müssen den Programmierern mitgeteilt werden, die Änderungen vorgenommen haben. Alternativ zur täglichen Ausführung, ist es auch vorstellbar, alle Tests auszuführen, sobald eine Änderungen in das System übernommen wird. Somit wird unmittelbar eine Rückmeldung geliefert, ob Fehler aufgetreten sind und die Fehlerquelle kann besser eingeschränkt werden Auswirkungen auf den Programmierstil Die Verwendung von Unit Tests hat unmittelbare Auswirkungen auf den Programmierstil. Dies trifft besonders beim Programmieren nach dem Prinzip des Test Driven Development zu, aber auch bei der späteren Einführung von Unit Tests. Die zu testenden Klassen müssen gewisse Anforderungen erfüllen, damit sie testbar sind. Dies kann, wie weiter oben beschrieben, durch ein Refactoring geschehen. Einige der dabei entstehenden Auswirkungen auf den Programmierstil sind sogar erwünscht, da dadurch der Programmierstil verbessert wird (vgl. [6] S.5). Eine Auswirkung hat das Programmieren nach dem Entwurfsmuster der Dependency Injection. Dadurch werden Abhängigkeiten zwischen Objekten in den Konstruktor einer Klasse verlagert, so dass alle abhängigen Objekte bei der Erzeugung eines Objektes angegeben werden müssen. Innerhalb einer Klassen dürfen keine Objekte lokal initialisiert werden. Dies erleichtert das Testen dieser Klassen deutlich. Insbesondere Mock Objekte lassen sich leichter verwenden, da sie problemlos der Klasse übergeben werden können. Eine weitere Auswirkung des Programmierens von Unit Tests ist das Umgehen von Singleton Klassen. Auch wenn diese des öfteren nützlich sind, ist deren Verwendung umstritten, weil sie Probleme verursachen können[27]. Singleton Klassen sind sehr umständlich zu testen, da sie nur über eine getinstance Methode erstellt werden können und keine Möglichkeiten vorhanden ist, die Klasse von außen zu steuern. Hinzu kommt noch, dass zu Singleton Klassen keine Mock Klassen erstellt werden können. Des Weiteren ergibt sich beim Schreiben von Unit Tests, dass die Schnittstellen einer Klasse nach außen besser durchdacht sind, weil die Funktionalität einer Klasse 18

25 3.5 Testkonzepte für Unit Tests durch die Unit Test abgedeckt und überprüft wird. Deshalb muss sorgfältig überlegt werden, welche Methoden überhaupt vorhanden sein müssen und ob diese public sein sollten. Allerdings sollte darauf geachtet werden, nicht zu viele Methoden auf public zu setzen, nur um sie besser testen zu können. So sollten beispielsweise Hilfsmethoden, die nur innerhalb einer Klasse verwendet werden, immer private Methoden sein Weitere Konzepte Im Zusammenhang mit Unit Tests gibt es verschiedene Ansätze auch Programmcode zu testen, der über das bisher Vorgestellte hinausgeht. Dazu gehört auch das Testen von verteilten Systemen oder von Code, der Multithreading verwendet. An dieser Stelle sollen zwei weitere Konzepte kurz vorgestellt werden. Diese spielen in dieser Arbeit eine untergeordnete Rolle, weil keine GUI-Tests sowie Datenbanktests durchgeführt werden, aber bei der Auswahl des Unit Test Frameworks erwähnt werden und die Möglichkeiten, auf welche Weise sich Unit Tests einsetzen lassen, zeigen. GUI-Tests Um die GUI (Graphical User Interface) einer Anwendung zu testen, werden entsprechende Erweiterungen für ein Unit Test Framework benötigt. Diese sind, auch abhängig von der Programmiersprache, nicht immer verfügbar. So besteht in C++ das Problem, dass die GUI stark plattformabhängig ist und entsprechend auch nur Tools das Testen von GUI Elementen unterstützen können, die für eine Plattform entwickelt wurden. Mithilfe zusätzlicher Methoden, die die Erweiterung bereitstellt, können GUI Fenster erzeugt, einzelne Elemente angesteuert und ihr Zustand abgefragt werden. Das Prinzip von GUI-Tests wiederspricht im Prinzip der Grundidee des Unit Testing, da hier auf einer sehr hohen Ebene getestet wird und es sich eigentlich um Integrationstests handelt. Dennoch sind Unit Tests auch für GUI-Tests hervorragend geeignet. Vorraussetzung dafür ist allerdings, dass die verwendeten Klassen, die die zugrundeliegende Logik der GUI implementieren, schon vollständig durch Unit Tests getestet sind. Testen mit Datenbanken Auch das Testen mit Datenbanken benötigt eine entsprechende Erweiterung für das Unit Test Framework, die im Wesentlichen dafür sorgt, dass die Datenbank automatisch wieder in einen definierten Zustand gebracht wird. Hierzu wird die Datenbank in der Set-Up Methode aufgebaut und die benötigten Tabellen angelegt, dabei werden die Informationen zum Beispiel aus einer Datei gelesen. In der Tear- 19

26 3.5 Testkonzepte für Unit Tests Down Methode wird die Datenbank wieder zurückgesetzt, wenn dies nicht schon automatisch passiert. In der Praxis ist dies meistens nicht so einfach zu realisieren, weil nicht alle Anwendungen auf die gleiche Weise mit einer Datenbank verbunden sind. Vielfach ist noch ein Adapter zwischen Datenbank und Programm geschaltet, der die Datenbankanfragen absetzt und die Ergebnisse zurückliefert. Mithilfe eines Adapters lassen sich problemlos verschiedene Datenbanken verwenden oder komplexe Objekte abspeichern, wobei keine SQL Anfragen geschrieben werden müssen. Abhängig von der jeweiligen Anwendung gibt es verschiedene Ansätze und entsprechende Tools. Eine tieferen Einstieg in diese Tools und deren Benutzung soll es hier aber nicht geben, weil keine Datenbanktests in dieser Arbeit durchgeführt werden. 20

27 4 Unit Test Frameworks für C++ Für die Programmiersprache C++ existieren eine Vielzahl von Unit Test Frameworks. In diesem Kapitel soll es darum gehen, einen Überblick über verfügbare Unit Test Frameworks zu geben und anhand von verschiedenen Entscheidungskriterien ein geeignetes Framework für das Projekt SUMO auszuwählen. 4.1 Warum existieren für C++ so viele Unit Test Frameworks? Beim Vergleich zwischen der Auswahl von Frameworks für C++ und Java fällt sofort auf, dass es für C++ eine Vielzahl existierender Frameworks gibt, während sich im Umfeld von Java nur wenige Frameworks entwickelt haben. So gibt es in Java mit JUnit ein Unit Test Framework, welches sich als Standard durchgesetzt hat. Dies belegen u.a. die Vielzahl von existierenden Büchern, die als Tutorial dienen, einen umfassenden Einblick in Unit Testing geben und JUnit als Beispielsprache benutzen. Darüber hinaus gibt es auch über das Internet eine große Zahl an Informationsquellen zu JUnit. Es drängt sich die Frage auf, warum sich für C++ kein ähnlich populäres Unit Test Framework entwickelt hat. Die Antwort liegt sicherlich in der Programmiersprache C++, die sich in vielen Details von Java unterscheidet, obwohl beide objektorientierte Sprachen sind. Einer der wichtigsten Unterschiede liegt in der Plattformabhängigkeit von C++. Viele Unit Test Frameworks für C++ sind speziell für eine Plattform entwickelt, um die Vorteile dieser Plattform auszunutzen. Darüber hinaus sind viele Frameworks auf die API eines Betriebssystems zugeschnitten. Dennoch gibt es auch eine Reihe von Unit Test Frameworks in C++, welche nicht abhängig von dem Betriebssystem sind. Mit diesen Frameworks ist es aber bisher nicht möglich GUI Tests oder Datenbanktests durchzuführen. Die Vielzahl der existierenden Frameworks erklärt sich auch einerseits aus ihrer Abhängigkeit zu verschiedenen Compilern, beispielsweise G++, Visual Studio C++, Borland C++, Intel C++, usw. Es gibt einige Unit Test Frameworks, die nur für bestimmte Compiler geschrieben wurden, zum Beispiel Team Test für Visual Studio C++. Anderseits gelingt es nicht allen Compilern, die im Jahr 1998 festgelegte Sprachnorm umsetzen. Der einzige Compiler, der zurzeit die Sprachnorm vollständig unterstützt, ist der Compiler Comeau C++. Verwenden Frameworks spezielle Spracheigenheiten sind sie nicht auf allen Compilern lauffähig. Darüber hinaus gibt es Frameworks, die die verschiedensten Bibliotheken benötigen oder RTTI (Runtime Type Information) verwenden. RTTI ermöglicht es, zur Laufzeit den Typ eines Objektes zu ermitteln. Mit diesen Abhängigkeiten, kommt es bei der Installation des Öfteren zu Schwierigkeiten, da nicht jede Bibliothek mit jedem Compiler harmoniert. Allgemein kann festgehalten werden, dass ein Unit Test Framework leichter zu verwenden ist, wenn es so wenig 21