Auswirkungen Testgetriebener Entwicklung (Test Driven Development, TDD)

Richard Metzler
Institut fr Informatik Universitt Potsdam
August-Bebel-Str. 89 14482 Potsdam, Deutschland

richard@launchco.com Kurzbeschreibung
Testgetriebene Entwicklung ist eine Software Entwicklungsmethode, bei der vom Entwickler automatisch ausfhrbare Tests geschrieben werden, bevor er die zu testenden Funktionalitt implementiert. Testgetriebene Entwicklung als Teil der Agilen Prozesse hat in den letzten Jahren sehr an Bedeutung gewonnen. Als Grnde dafr werden von Befrwortern die durch Testgetriebene Entwicklung erhhte Software-Qualitt, hhere Produktivitt der Entwickler und geringere Code-Komplexitt gegenber nicht oder spt getestetem Code genannt. Wir beschftigen uns damit, was Testgetriebene Entwicklung ist und welche Auswirkungen diese Methode auf Software-Projekte hat. Dazu werden verschiedene Studien analysiert und miteinander verglichen. Zustzlich werden Empfehlungen zur Einfhrung von Testgetriebener Entwicklung gegeben. knnen. Die gewnschte Wiederholbarkeit von Erfolgsrezepten hat dabei zu einer Formalisierung der Methoden gefhrt. Definierte Vorgehensweisen und Prozesse, Visualisierung des Projektfortschritts und zugleich die qualittssichernden Manahmen des Extreme Programming (XP) [5] wie Peer Reviews, Pair Programming, Testgetriebene Entwicklung (Test Driven Development, TDD), Versionsverwaltung und Continous Integration dienen dazu die Prozesse planbarer zu machen und den Projekterfolg zu sichern. Dabei beschreiben agile Prozesse oftmals iterative Vorgehensweisen, die regelmig Fortschritte und Ziele evaluieren. Dabei soll sichergestellt werden, auch whrend des Entwicklungsprozesses stets ein benutzbares Produkt ausliefern zu knnen. [6] So werden z.B. im Scrum Entwicklungsprozess zu Beginn einer Iteration ("Sprint") die zu erreichenden Ziele festgelegt und am Ende des Sprints mit dem erreichten Ergebnis verglichen. In folgenden Sprints kann man dann diese Erfahrungen in die Planung mit einflieen lassen und so zu wesentlich realistischeren Abschtzungen kommen oder Fehlentwicklungen frhzeitig korrigieren. Ein Sprint dauert zwischen einer Woche und zwei Monaten und ist damit wesentlich krzer als der Prozess im Wasserfall Modell. Wir wollen uns im Folgenden nher mit der Testgetriebenen Entwicklung (TDD) als Teil der Agilen Prozesse befassen. TDD beschreibt einen iterativen Mikro-Prozess, dessen Iterationen innerhalb von Minuten oder Stunden durchlaufen werden. Dabei werden vom Software-Entwickler automatisch ausfhrbare Tests programmiert, bevor der eigentlich bentigte Produktionscode implementiert wird. Dadurch wird ein Groteil des Programms getestet und Software-Fehler schon frhzeitig whrend der Entwicklung erkannt, und nicht erst in spteren Phasen des Software-Lebenszyklus. [17] Im Folgenden befassen wir uns mit den Auswirkungen von TDD auf Software-Qualitt und Entwicklungszeit in SoftwareEntwicklungsprozessen. Dazu werden in Abschnitt 2 die verschiedenen Mglichkeiten von Software-Tests analysiert und die Vorteile des automatisierten Testens hervorgehoben. Abschnitt 3 beschftigt sich mit dem Prozess der Testgetriebenen Entwicklung, whrend sich Abschnitt 4 mit den verffentlichten Studien zu den Auswirkungen von TDD befasst. Eine Zusammenfassung und Einschtzung der Ergebnisse findet man in Abschnitt 5.

Stichworte
Testgetriebene Entwicklung, Test Driven Development, TDD, Agile Prozesse 1. Einleitung Traditionelle Vorgehensweisen bei der Software-Entwicklung wie z.B. das Wasserfall-Modell haben in der Vergangenheit hufig Probleme bei der Durchfhrung von Software-Projekten verursacht. Die vorgegebenen Anforderungen waren oftmals zu star und zu weit in die Zukunft geplant. Die vorgesehene Zeitdauer fr das Wasserfall-Prozessmodell betrgt normalerweise mehrere Monate bis etwa zwei Jahre. Regelmige berprfungen des Projektplans, qualittssichernde Manahmen und eventuelle Anpassungen an unvorhergesehene Anforderungen sind darin nicht oder nur unzureichend vorgesehen. Deshalb konnten in der Vergangenheit viele Software-Entwicklungsprojekte nicht erfolgreich abgeschlossen werden. [6] [10] Als Reaktion auf diese Problematik wurden Agile Prozesse entwickelt. [9] Darunter versteht man eine Reihe eine Reihe von Methoden, die das Ziel haben, die Projektentwicklung prziser abschtzen zu knnen, Probleme frhzeitig zu erkennen und leichter Einfluss auf den Erfolg eines Projektes ausben zu
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Conference10, Month 12, 2010, City, State, Country. Copyright 2010 ACM 1-58113-000-0/00/0010$10.00.

2. Software-Tests Software-Tests sollen die korrekte Funktionalitt der Software sichern. Sie tragen wesentlich zur Erhhung der Software-Qualitt und zur Strkung des Vertrauens in die Software bei. Tests knnen sowohl manuell als auch automatisch durchgefhrt werden. Generell muss jede Software, die ber eine grafische Benutzeroberflche verfgt, auch manuell getestet werden. Der Tester kann dabei entweder systematisch oder unsystematisch vorgehen. Das systematische Vorgehen mit Testprotokollen und vorher definierten Erwartungen hat den Vorteil, dass die Tests explizit dokumentiert und damit jederzeit wiederholbar sind. Dies ist bei einem unsystematischen Testen nicht mglich, allerdings fhrt unsystematisches Testen oft schnell zu neuen Erkenntnissen und deckt unzureichende Anforderungen auf. Jederzeit wiederholbar sind auch automatische Tests. Zugleich ist die Geschwindigkeit mit der diese Tests vom Computer ausgefhrt werden knnen, sehr viel hher als beim manuellen Testen. Dadurch wird es mglich, dass man diese Software-Tests beliebig oft ausfhren bzw. regelmig wiederholen kann und so schneller auf neu auftretende Fehler stt. Die automatische Testausfhrung hilft auerdem, Tests, die die Erwartungen erfllt haben zusammenzufassen und fehlgeschlagene Tests visuell besonders hervorzuheben. Fehlerfrei durchlaufende Tests werden dabei meist grn dargestellt, fehlschlagende Tests rot. Deshalb spricht man in diesem Zusammenhang auch oft von grnen und roten Tests. In Abhngigkeit vom Abstraktionsgrad der Software-Tests, existieren verschiedene Testen-Arten, wie beispielsweise UnitTests, Akzeptanz- bzw. Integrationstests, und Performance-Tests. TDD bezieht sich dabei vor allem auf Unit-Tests, also die Tests fr die kleinsten Einheiten eines Programms. Es existiert eine groe Anzahl an Frameworks, die diese Art des Testens untersttzen. Dazu gehrt u.a. die xUnit Familie mit ihrem bekanntesten Vertreter JUnit von Kent Beck. [8] Der Zeitpunkt, zu dem man Unit-Tests schreibt, kann vor oder nach der Implementierung des zu testenden Codes liegen. Obwohl es unlogisch klingen mag, dass man Tests noch vor der eigentlichen Implementierung schreibt (Test-First), hat diese Vorgehensweise doch einige Vorteile. In der Regel werden die Tests bei einem Test-Last Ansatz vom Entwickler nicht systematisch geschrieben und decken damit nur einen Teil der Funktionalitt ab. Generell besteht die Gefahr, dass das Schreiben von Tests vernachlssigt wird. [14] Im Unterschied dazu betrachtet der Entwickler bei TDD die zu testende Einheit als Blackbox und schreibt die Tests so, wie die Schnittstelle idealerweise aussehen sollte. Dabei macht er sich insbesondere Gedanken ber Fehlerquellen und Randbedingungen. Deshalb hat TDD den Vorteil, Fehler frhzeitig aufzudecken, wodurch die Kosten zur Beseitigung von SoftwareFehlern reduziert werden. Refactoring [13] nennt man die nderung der internen Struktur einer Software, ohne dass sich deren von auen beobachtbares Verhalten ndert. Durch Refactoring soll vor allem Lesbarkeit und Wiederverwendbarkeit verbessert werden; aber auch die Optimierung von Algorithmen zhlt zum Refactoring. Automatische Tests stellen dabei sicher, dass sich das beobachtete Verhalten nicht verndert und wirken praktisch wie ein Sicherheitsnetz. Dadurch beschleunigen sie die Umsetzung von nderungen und sichern die korrekte Funktionalitt der Software. Auerdem stellen sie sicher, dass der Programmcode von anderen

Entwicklern, der auf dem refaktorierten Code aufbaut, auch nach den nderungen fehlerfrei funktioniert. Continuous Integration (CI) bezeichnet einen parallel zur Entwicklung automatisch ablaufenden Prozess. Dabei bezieht ein CI-Server tglich die neueste Version des Quellcodes aus der Versionsverwaltung, compiliert die Quellen und fhrt alle automatischen Tests aus. Schlgt das Compilieren oder einer der Tests fehl, werden die beteiligten Entwickler automatisch benachrichtigt. CI hilft somit, schneller auf Fehler im Programmcode zu reagieren. 3. Testgetriebene Entwicklung Testgetriebene Entwicklung ist nicht gleichbedeutend mit dem automatisierten Testen von Software. Es handelt es sich vielmehr um eine Prozess-Methode, bei der es vor allem um den Zeitpunkt geht, zu dem die Tests geschrieben werden. Deshalb spricht man bei TDD auch von einem Test-First Ansatz im Unterschied zum traditionellen Test-Last Ansatz bei dem der Entwickler erst im Nachhinein testet. Im Einzelnen fhrt der Entwickler bei der Testgetriebenen Entwicklung folgende Schritte aus: - Schreiben eines, oder einer kleinen Anzahl automatisierter UnitTests. - Ausfhren der Tests. Da noch kein Produktionscode implementiert ist, sollten die Tests zuerst fehlschlagen. - Implementieren des Produktionscodes, so dass die Tests erfllt werden sollten. - Erneutes Ausfhren der Tests um sicherzustellen, dass die getestete Funktionalitt korrekt implementiert wurde. Falls das der Fall ist, luft der Test jetzt durch. - Refaktorieren, falls ntig. Die Tests stellen sicher, dass das beobachtete Verhalten erhalten bleibt. Ungenutzter Code sollte entfernt werden. - Regelmiges Ausfhren aller Unit-Tests, insbesondere vor und nach der Integration von Programmcode verschiedener Entwickler. Neue Funktionalitt wird dabei erst dann als korrekt implementiert angesehen, wenn sowohl die neu hinzugefgten als auch die bisherigen Tests fehlerfrei durchlaufen. Dieser TDD-Ablauf kann an dem Flussdiagram in Abbildung 1 genauer nachvollzogen werden. 3.1 Vorteile der Testgetrieben Entwicklung Testgetriebene Entwicklung hat gegenber einem traditionellen Test-Last Ansatz, bei dem die Tests erst nach der Implementierung des Produktionscodes geschrieben werden, folgende mgliche Vorteile: - Effizente Prfung und Rckmeldung. Die kurzen Zyklen des TDD ermglichen effiziente Prfung und kontinuierliche Rckmeldungen ber den Entwicklungsstand und die Korrektheit des Produktionscodes in Bezug auf die Tests. - Design der Low-Level Schnittstellen. Entwickler erhalten durch die Tests eine Spezifikation, die ihnen hilft unntige Funktionen zu vermeiden. Isoliertes Testen der einzelnen Module im Unit-Test bewirkt auerdem, dass die verschiedenen Softwaremodule strker entkoppelt sind. Dadurch steigt die

Software Qualitt, denn lose gekoppelte Software-Module haben wesentliche Vorteile hinsichtlich ihrer Wartbarkeit, Erweiterbarkeit und Wiederverwendbarkeit. - Schutz vor neuen Fehlern. Die geschriebenen Tests bilden ein Sicherheitsnetz um neu eingebaute Fehler frhzeitig zu erkennen. Das kommt dem Software Projekt vor allem in Erweiterungs- und Wartungsphasen zugute, wenn Anpassungen der Funktionalitt vorgenommen werden sollen. - Tests haben zustzlichen Wert. Dadurch, dass automatische Tests geschrieben und innerhalb des Projektes versioniert werden knnen, bleiben sie dem Projekt jederzeit erhalten. Die dabei entstehende Test-Suite ist nicht nur eine wertvolle Hilfe bei der Wartung und Erweiterung der Software im gesamten Lebenszyklus sondern dient den Entwicklern auerdem als stets aktuelle Dokumentation. Das beschriebene Vorgehen des TDD hat insbesondere Vorteile bei der Behebung von spt entdeckten Fehlern, die z.B. erst in der Qualittssicherung oder beim Anwender auffallen. [13] TDD verhindert in solchen Fllen, dass Folgefehler bei der Fehlerbehebung in den Programmcode eingebaut werden, da die frher geschriebenen automatischen Tests wirksam bleiben. Studien zeigen auch, dass viele Programmierer Tests als sehr positiv beim debuggen ihres Codes wahrnehmen. [11] Durch das Schreiben eines automatischen Tests wird der Fehler zuerst reproduziert. Der fehlschlagende Test ist dabei der Beweis fr einen Defekt im Programmcode. Nachdem man den Defekt behoben hat, muss auch der Test fehlerfrei durchlaufen und liefert damit automatisch den Beweis, dass der vorher reproduzierte Fehler behoben wurde. Die auerdem ausgefhrten bisherigen Tests sichern dabei ab, dass bei der Fehlerbehebung keine neuen Fehler in den Programmcode eingebaut werden. 4. Studien zu TDD Es existieren sowohl akademische Studien zu TDD als auch Studien der Industrie. Ein Groteil der verffentlichten Studien vergleicht dabei TDD mit einem Test-Last Ansatz. Verglichen werden meist die Qualitt des Programmcodes und Produktivitt der Entwickler. Um die Code Qualitt zu quantifizieren, wurden verschiedene Metriken als Indikator verwendet. 4.1 Akademische Studien In Software Architecture Improvement through Test-Driven Development [14] erhielten mehrere Teams die gleiche Aufgabe und sollten sie entweder mit einem Test-First oder Test-Last Ansatz bearbeiten. Ein Teil der Probanden dieser Studie bestand aus Studenten, ein anderer Teil der Probanden war als Programmierer bei einer groen Firma beschftigt. In der Studie sollte herausgefunden werden, ob Programmierer mit TDD produktiver sind und ob TDD zu einem verbesserten Software Design fhrt. Dazu wurden sehr viele Code-Metriken erstellt und die Probanden befragt. Die Authoren berichten davon, dass der Test-First Ansatz zu einer signifikant hheren Anzahl von Tests und hherer TestAbdeckung fhrte. Die Anzahl der Klassen, losere Kopplung, Verschachtelungstiefe und Zyklomatische Komplexitt weisen auf ein signifikant besseres Design als bei der Kontrollgruppe hin. Die Studie kommt zu dem Schlu, dass Test-First Programmierer in der Regel produktiver sind als Programmierer in Test-Last Projekten. Zudem glaubten die Programmierer der Test-First Gruppe eher, dass zuknftige nderungen an ihrer Software mglich sind.

In A structured experiment of test-driven development [15] wurde Produktivitt und Code Qualitt von TDD im Vergleich mit Kontrollgruppen gemessen. Alle Gruppen bearbeiteten das gleiche Beispiel und verwendeten dabei Pair Programming. Als Metrik fr die Code Qualitt wurde die Test-Abdeckung herangezogen. Im Mittel erreichten die TDD Gruppen eine bessere TestAbdeckung. Dafr bentigten sie allerdings auch mehr Zeit. Die anschlieende Umfrage unter den Teilnehmern der Studie kam zu dem Schlu, dass die Programmierer das Gefhl hatten, mit TDD produktiver zu sein und besseren Code zu schreiben. Allerdings fanden sie es schwierig, TDD anzuwenden und uerten Bedenken hinsichtlich der zum Schreiben der Tests bentigten Entwicklungszeit. Kaufmann und Janzen [7] fhrten ein Experiment mit 2 Teams aus jeweils 4 Studenten mit unterschiedlicher Erfahrung ber einen lngeren Zeitraum durch. Die Teams durften selbst entscheiden, was sie programmieren wollten. Im Verlauf des Experiments wurden mehrmals Snapshots des Codes analysiert und verschiedenste Metriken erstellt. Anschlieend wurden die Probanden befragt. Die Autoren stellen fest, dass die Test-First Gruppe produktiver war und im Anschlu mehr Vertrauen in ihren Code hatten. Die Probanden uerten auch, dass die Tests ihnen beim Debugging und Design ihrer Klassen geholfen htten. Allerdings stellen die Autoren klar, dass es sich bei der Studie um ein Pilot-Projekt handelt und die Samplegre viel zu klein ist, um statistisch signifikant zu sein.

Abbildung 1. Testgetriebene Entwicklung Flussdiagram [4]

4.2 Studien der Industrie Eine industrielle Studie [12] fasst mehrere Projekte von IBM und Microsoft zusammen, deren Einzelergebnisse teilweise vorher in eigenen Studien [1] [4] [16] verffentlicht worden waren. Dabei wurde jeweils ein TDD Projekt mit einem hnlichen nicht-TDD Projekt derselben Firma bzw. Abteilung verglichen. Als Indikator fr Code Qualitt wurde die Fehler-Dichte die Anzahl der bekannten Defekte aus den jeweiligen Fehler-Datenbanken pro 1000 Zeilen Quellcode verwendet. Auerdem wurde anschlieend der zeitliche Mehraufwand fr TDD durch das Projekt-Management geschtzt. Die Projekte bestanden aus jeweils mehreren tausend Zeilen Quell- und Test-Code in verschiedenen Programmiersprachen und wurden von Teams mit unterschiedlichem Erfahrungsgrad neu entwickelt. Die Ergebnisse der Studie sind in Tabelle 1 dargestellt. Die Studie stellt fest, dass TDD die Fehler-Dichte erheblich senkt: um 40% fr das IBM Team und 6090% fr die Microsoft Teams. Der geschtzte zeitliche Mehraufwand in der Entwicklungszeit betrug dabei 15-35%. Die Studie stellt allerdings auch fest, dass dieser Mehraufwand in der Entwicklungszeit spter durch die reduzierten Wartungskosten wegen besserer Software Qualitt wettgemacht wird. Insgesamt ist diese Studie der Industrie vor allem deshalb bemerkenswert, weil die Projektgre wesentlich realistischer ist als es in den akademischen Studien der Fall ist. Janzen und Saiedian [2] fhrten mehrere Studien mit erfahrenen und unerfahrenen Entwicklern durch und verglichen dabei Teams mit Test-First und Test-Last Ansatz hinsichtlich der Auswirkungen auf Zeilenanzahl, Komplexitt, Kopplung und Kohsion des Programmcodes. Sie kamen zu dem Schluss, dass TDDProgrammierer mit hherer Wahrscheinlichkeit Software schreiben, die aus kleineren und besser getesteten Modulen besteht. Hinsichtlich der Kohsion und Kopplung scheinen sich die Autoren nicht sicher zu sein, wie sie ihre Messwerte interpretieren sollen. Insbesondere die Java-spezifischen Eigenheiten wie Zugriffsmethoden fr Attribute scheinen besondere Auswirkungen auf die verwendeten Metriken zu haben. In Evaluating advantages of test driven development: a controlled experiment with professionals [3] lsten 28 Software-Entwickler zwei verschiedene Aufgaben. Auch hier gab es eine TDD und eine

Kontrollgruppe. Fr die Lsung der Aufgaben hatten sie jeweils 30 bzw. 65 Minuten Zeit. Die Authoren kamen zu dem Schlu, dass es statistische Beweise gbe, dass TDD mehr Zeit bentigt als Test-Last. Allerdings sind sie berzeugt, dass TDD qualitativ bessere Software liefert. Insgesamt haben die Autoren bei dieser Studie eine Prfung der Langzeitwirkung von TDD vollstndig ausgelassen. 5. Empfehlungen Insbesondere die Authoren von Realizing quality improvement through test driven development: results and experiences of four industrial teams [12] geben Empfehlungen darber, wie Entwickler-Teams am besten an TDD herangefhrt werden sollen. - TDD sollte mglichst zu Beginn eines Projektes eingefhrt werden, denn so bringt der inkrementelle und kontinuierliche Aspekt von Testgetriebener Entwicklung den grten Nutzen. TDD abzubrechen oder zu spt einzufhren ist hinderlich. - Immer wenn ein neues Problem entdeckt wird, sollte auch ein neuer Test erstellt werden. Dadurch wchst die Test-Suite und damit die Test-Abdeckung in allen Phasen des SoftwareLebenszyklus. - Tests sollten zusammen mit dem Programmcode versioniert werden. Dadurch werden Tests auch mit den anderen Entwicklern geteilt, die diese als zustzliche Dokumentation verwenden knnen. - Das Test-Team sollte neue Features nur akzeptieren, wenn die dazu gehrigen Tests fehlerfrei durchlaufen. Features ohne Tests sollten nicht akzeptiert werden. - Alle Tests sollten regelmig ausgefhrt werden, z.B. durch einen CI-Server. Dadurch fallen fehlschlagende Tests schnell auf und das Vertrauen in die korrekte Funktionalitt der Software wird gestrkt. Allerdings sollte Continuous Integration nicht zu frh eingefhrt werden. Zu Beginn des Projektes soll stattdessen jeder Entwickler alle Tests regelmige auf dem eigenen Rechner ausfhren. - Die Tests sollten mglichst bequem gestartet werden knnen und schnell durchlaufen, damit die Entwickler hufig testen und nicht aus Bequemlichkeit die Tests abschalten oder gar keine Tests mehr schreiben. Automatisierte Testausfhrung beim Speichern einer Datei oder per Tastenkombination bietet sich dazu an und ist in vielen Programmiersprachen und IDEs mglich.

Tabelle 1. Ergebnisse von 4 TDD Projekten der Industrie im Vergleich zu nicht-TDD Projekten [12] Metrik Anzahl Zeilen Quellcode (KLOC) des TDD Projektes Anzahl Zeilen Testcode (KLOC) des TDD Projektes Anzahl Zeilen (KLOC) des verglichenen nicht-TDD Projekts Fehler-Dichte des verglichenen nicht-TDD Projekts Fehler-Dichte des TDD Projektes Durch TDD verursachter Mehraufwand (Schtzung des Managements) IBM: Treiber 41,0 28,5 56,6 W 0,61W 15-20% Microsoft: Windows 6,0 4,0 4,3 X 0,38X 25-35% Microsoft: MSN 26,0 23,2 149,0 Y 0,24Y 15 % Microsoft: VS 155,2 60,3 222,0 Z 0,09Z 25-20%

6. Fazit Die beschriebenen Studien haben gezeigt, dass Testgetriebene Entwicklung zu einer wesentlich hheren Software Qualitt fhrt. Der dafr bentigte Mehraufwand muss natrlich einkalkuliert werden, ist aber berschaubar und unseres Erachtens nach mehr als gerechtfertigt. Insbesondere die zu Beginn unbekannte Lnge des Software Lebenszyklus und der Umstand, dass Wartungs- und Ergnzungsphasen oft nicht vorrausschauend planbar sind, gebietet es, mglichst viel in die Software Qualitt zu investieren. Positive Auswirkungen hat Testgetriebene Softwareentwicklung insbesondere auf die Programmierer des Projekts. In mehreren Studien uerten sie strkeres Vertrauen in ihren Code und gaben an, dass Tests ihnen bei der Fehlersuche helfen. Auerdem deuten einige Studien darauf hin, dass Programmierer sich selbst mit Testgetriebener Entwicklung als produktiver wahrnehmen. Interessant wre es, zu erfahren ob Test-Last Programmierer frustrierter bei ihrer Arbeit sind als TDD-Programmier. Einige Aspekte der Testgetriebenen Entwicklung wurden in diesem Paper nur angeschnitten. So wurden bisher nur studentische und industrielle Software-Projekte ausgewertet. Interessant wre es, Open Source Projekte auf einen Zusammenhang zwischen TDD und Code Qualitt zu untersuchen. Insbesondere die unterschiedliche Entwicklungen von originalen Open Source Projekten und deren Abspaltungen (Forks), bten eventuell Anstze zu wissenschaftlicher Forschung. TDD bezieht sich vor allem auf Unit-Tests. Mittlerweile gibt es aber mit Behaviour Driven Development (BDD) auch eine an TDD angelehnte Methode, wie man agil von User Stories zu Akzeptanz-Tests gelangt. Interessant wre es auerdem, die Mglichkeiten von TDD im Zusammenhang mit dem Erlernen einer Programmiersprache auszuloten. Verschiedene Open Source Projekte [19] [20] [21] und Startups [18] basieren auf der Idee, dass Lernenden Programmieraufgaben gestellt werden, die durch automatische Tests auf ihre Korrektheit geprft werden. Der Lernende erhlt so kontinuierlich Rckmeldungen darber, welche Inhalte er verstanden hat. Aber auch agile Methoden und Werkzeuge wie TDD, Versionskontrolle und Continuous Integration sollten in der Ausbildung zuknftiger Entwickler frhzeitig behandelt werden.

[4] Bhat, Thirumalesh ; Nagappan, Nachiappan: Evaluating the efficacy of test-driven development: industrial case studies. In: ISESE '06: Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering. New York, NY, USA : ACM, 2006. - ISBN 1-59593-218-6, S. 356-363 [5] Beck, Kent: Extreme Programming Explained: Embrace Change. US ed : Addison-Wesley Professional, 1999. [6] Leitass, Martins ; Is Agile Better? Research of Studies.. In: ICT Tools and Methods, 2010. [7] Kaufmann, Reid ; Janzen, David: Implications of test-driven development: a pilot study. In: OOPSLA '03: Companion of the 18th annual ACM SIGPLAN conference on Objectoriented programming, systems, languages, and applications. New York, NY, USA : ACM, 2003. - ISBN 1-58113-751-6, S. 298--299 [8] http://www.junit.org/ [9] Beck, Kent ; Beedle, Mike ; van Bennekum, Arie ; Cockburn, Alistair ; Cunningham, Ward ; Fowler, Martin ; Grenning, James ; Highsmith, Jim ;Hunt, Andrew ; Jeffries, Ron ; Kern, Jon ; Marick, Brian ; Martin, Robert C. ; Mellor, Steve ; Schwaber, Ken ; Sutherland, Jeff ; Thomas, Dave: Manifesto for Agile Software Development, 2001 [10] Huo, Ming ; Verner, June M. ; Zhu, Liming ; Babar, Muhammad Ali: Software Quality and Agile Method.. In: COMPSAC : IEEE Computer Society, 2004. - ISBN 0-7695-2209-2, S. 520-525 [11] Williams, Laurie ; Kudrjavets, Gunnar ; Nagappan, Nachiappan: On the Effectiveness of Unit Test Automation at Microsoft.. In: ISSRE :IEEE Computer Society, 2009. - ISBN 978-0-7695-3878-5, S. 81-89 [12] Nagappan, Nachiappan ; Maximilien, E. Michael ; Bhat, Thirumalesh ; Williams, Laurie: Realizing quality improvement through test driven development: results and experiences of four industrial teams.. In: Empirical Software Engineering, 13 (2008), Nr. 3, S. 289-302 [13] Fowler, Martin: Refactoring: Improving the Design of Existing Code : Addison Wesley Professional, 1999 [14] Janzen, David ; Johnson, Ralph (Bearb.) ; Gabriel, Richard P. (Bearb.): Software architecture improvement through testdriven development.. In: OOPSLA Companion : ACM, 2005. - ISBN 1-59593-193-7, S. 222-223 [15] George, Boby ; Williams, Laurie: A structured experiment of test-driven development. In: Information and Software Technology, 46 (2004), Nr. 5, S. 337-342 [16] Williams, L. ; Maximilien, E.M. ; Vouk, M.: Test-driven development as a defect-reduction practice. In: Software Reliability Engineering, 2003. ISSRE 2003. 14th International Symposium on (2003), S. 34-45 [17] Janzen, D. ; Saiedian, H.: Test-driven development concepts, taxonomy, and future direction. In: Computer, 38 (2005), Nr. 9, S. 43-50 [18] http://www.codecademy.com/ [19] http://rubykoans.com/ [20] https://github.com/mrdavidlaing/javascript-koans [21] https://github.com/sleepyfox/coffeescript-koans

7. REFERENZEN [1] Maximilien, E.M. ; Williams, L.: Assessing test-driven development at IBM. In: Software Engineering, 2003. Proceedings. 25th International Conference on (2003), S. 564-569. [2] Janzen, David S. ; Saiedian, Hossein: Does Test-Driven Development Really Improve Software Design Quality?. In: IEEE Software, 25 (2008), Nr. 2, S. 77-84 [3] Canfora, Gerardo ; Cimitile, Aniello ; Garcia, Felix ; Piattini, Mario ; Visaggio, Corrado Aaron: Evaluating advantages of test driven development: a controlled experiment with professionals. In: ISESE '06: Proceedings of the 2006 ACM/ IEEE international symposium on Empirical software engineering. New York, NY, USA : ACM, 2006. - ISBN 1-59593-218-6, S. 364--371