Saubere Software durch TDD?

Wie testgetriebenes Entwickeln zu besserer Codequalitt fhrt

Jan Brennenstuhl, B.Sc. jan.brennenstuhl@uni-potsdam.de ABSTRACT
Testgetriebene Entwicklung (engl. Test-Driven Development, TDD) als eine der Leitmethoden agiler Software-Entwicklung verspricht mit umfangreichen Mglichkeiten das oft intuitio ve Kreieren von Programmen eektiv abzusichern, auf diese Weise nachhaltige Programme zu erschaen und zugleich das Verstndnis der EntwicklerInnen fr die Funktionsweise a u ihres Produktes zu erhhen - dennoch ndet dieser Ansatz o nur begrenzt Akzeptanz in der Software-Gemeinde. Ziel dieser Arbeit ist es deshalb, anhand verschiedener Direktiven und Paradigmen testgetriebener Entwicklung zu uberprfen, u inwiefern diese wirklich zu einer Verbesserung der Software fhren knnen, wobei im Folgenden auch auf die allgemeinen u o Ziele agiler Software-Entwicklung Bezug genommen wird. Erwartet wird, dass sich das durchdachte Ubernehmen von TDD in den produktiven Betrieb positiv auf die Codequalitt auswirkt und somit der allgemeinen Software-Qualitt a a zu Gute kommt.

Institut fr Informatik Universitt Potsdam

1.

EINLEITUNG

Kategorien und Beschreibungen

D.2.4 [Software/Program Verication]: Correctness proofs; D.2.5 [Testing and Debugging]: Code inspections and walk-throughs

Allgemeine Begriffe
Design, Management

Die Methoden und leichtgewichtigen Prozesse agiler Software-Entwicklung, zu denen neben Paarprogrammierung, Story Cards und schnellen Code-Reviews auch die stndige Rea faktorisierung und die im weiteren Verlauf betrachtete testgetriebene Entwickung gehren, haben seit ihrer Quasi-Deo nition und der entlichkeitswirksamen Verentlichung o o durch das Manifesto for Agile Software Development[5] im Jahr 2001 groe Aufmerksamkeit auf sich gezogen. So listet allein die Online-Suche der amerikanischen Webseite des weltweit agierenden Online-Warenhauses Amazon.com, Inc. im Februar 2012 uber 1,600 Publikationen die den Be gri Agile software development im Namen tragen oder direkt mit ihm assoziiert sind. Dennoch scheinen diese noch relativ jungen, agilen Vorgehensmodelle noch immer nur eine Randerscheinung in der Industrie zu sein. Der deutsche Bundesverband fr Informationswirtschaft, Telekommunikau tion und neue Medien e. V. (BITKOM) jedenfalls erwhnt a in seinem Leitfaden fr Industrielle Softwareentwicklung[2] u agile Methoden zwar mit wenigen Worten, allerdings nur in Nebenstzen. Dabei sollten allein die Ziele des agiler Vorgea hens, nmlich die Flexibilisierung und Verschlankung des a Software-Entwicklungsprozesses, zumindest bei EntwicklerInnen und ProjektleiterInnen Gehr und Anwendung no den.

Schlagworte
TDD, Test-Driven Development, XP Practices, Inspections, Testing Diese Arbeit entstand im Rahmen der Veranstaltung Ent wicklung mobiler (Lern-)Apps fr Android Smartphones u und Tablets am Institut fr Informatik der Universitt u a Potsdam. Der nicht-kommerziellen, privaten Nutzung oder der Verwendung im Rahmen von Lehre und Forschung unter Nennung der Urheberschaft wird ausdrcklich zugestimmt. u Fr Anfragen zwecks kommerzieller Nutzung schreiben Sie u bitte dem Autor.

Indem agile Praktiken so weit wie mglich auf organisatorio sche oder dokumentarische Ttigkeiten verzichten und den a zu erstellenden Quelltext (im weiteren Verlauf als Code bezeichnet) sowie die kontinuierliche Zusammenarbeit mit dem Kunden in den Vordergrund stellen, bilden sie einen Gegenentwurf zu klassischen Vorgehensmodellen wie dem Wasserfallmodell oder dem V-Modell [10]. Auf Basis grundlegender Werte wie Kommunikation, Einfachheit, Feedback und Eigenverantwortung[4] soll weiterhin ein Mehr an SoftwareQualitt generiert werden, das auf Seiten der Programmierea rInnen nicht nur das Vertrauen in die eigene Software erhht, o sondern ebenfalls das Vertrauensverhltnis der Kunden zur a gelieferten Software strkt [11]. a

Um verstehen zu knnen, wie agiles Vorgehen und insbesono dere die Praktik der testgetriebenen Entwicklung die Software-Qualitt positiv beeinussen kann, wird im Folgenden a zunchst untersucht, wodurch sich qualitativ hochwertiger a Code auszeichnet und der Ist-Zustand in der Software-Qualittssicherung beschrieben, bevor anschlieend nher auf die a a

TDD und ihre Chancen eingegangen wird.

Auswirkungen von TDD auf die Software-Qualitt im Alla gemeinen heranziehen.

2.

CODEQUALITT 3. SOFTWARE-QUALITTSSICHERUNG
Trotz umfangreich erprobter und mitunter quasi-standardisierter Vorgehensmodelle fr die Software-Entwicklung tun u sich bei Unternehmen zahlreiche Dezite im Bereich SoftwareQualittssicherung (engl. Software Quality Assurance, SQA) a auf. Zu diesem Schluss kommt das Marktforschungs- und Beratungsunternehmen IDC in ihrer Studie [1] vom November und Dezember 2011, bei welcher 201 ausgewhlte deuta schen Unternehmen mit jeweils mehr als 100 MitarbeiterInnen zur aktuellen Situation rund um das Thema SoftwareQualittssicherung befragt wurden. So werden als Ergebnisa se der Studie neben der mangelnde[n] Abstimmung zwi schen Anwendungsentwicklern und Testern, eine[r] unzureichende[n] organisatorische[n] Verankerung des Testing, ein[em] geringe[n] Automatisierungsgrad des Testens auch die Wahl ungeeigneter Testmethoden als Ursachen fr die unzureiu chende Qualitt benannt. a

Der klassischen Ansicht in [3] folgend wird Software-Qualitt a hug als die Gesamtheit der Merkmale und Merkmalswera te eines Software-Produkts [beschrieben], die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfllen. Leider geht aus dieser sehr oberchliu a chen, produktspezischen Sichtweise nicht hervor, weshalb es uberhaupt von Interesse ist qualitativ hochwertigen Code zu schreiben oder warum es in anderen Worten nicht nur fr u ProgrammiererInnen sondern auch fr ihre Kunden wichu tig ist sauberen Code als Qualittsstandard durchzusetzen, a schlielich kann die von Balzert postulierte, auf Anforderungsdenitionen ausgerichtete Qualitt (die Software era fllt ihren Zweck, also ist sie gut) auf ganz unterschiedliche u Art und Weise erreicht werden. Dabei ist genau dieser Code die programmatische Spezikation von Softwareanforderungen [8] und somit in hchstem Mae Grundlage auch der von o Balzert gesetzten Ansprche an gute Software. u

Soll guter von schlechtem Code abgegrenzt werden, muss zunchst festgehalten werden, dass es keine wissenschaftlich a fundierten Faktoren fr eine explizite Unterteilung gibt, was u vordergrndig an der Tatsache liegt, dass es sich bei der Softu wareentwicklung um einen hchst kreativen Prozess handelt. o Zwar gibt es quasi-standardisierte Vorgehensmodelle nach denen Software entwickelt wird, fr das Erschaen von Cou de jedoch existieren wenn uberhaupt nur sogenannte Best Practises, Entwurfsmuster (Patterns) oder Style-Guides mit wenig obligatorischem Charakter - das Aussehen des Codes und somit auch seine Qualitt obliegt folglich den Softwarea EntwicklerInnen.

Zwar lsst sich laut der Studie mit Zeit- und Budget-Proba lemen weiterhin auch ungengendes Projektmanagement als u Grund fr nur eingeschrnkt ausreichende Qualittssicheu a a rung isolieren, abschlieend empehlt sie dennoch den Fokus vor allem auf umfangreiche Systemtests zu legen und ein Softwareprojekt mglichst viele Teststufen in hoher Qualitt o a durchlaufen zu lassen um so in Zukunft wesentliche Fehler frhzeitig erkennen und auf diese Weise umfangreiche Nachu besserungen vermeiden zu knnen [1]. o

Dennoch lsst sich Codequalitt beschreiben. So unterscheia a det sich sauberer, guter Code in erster Linie durch seinen klar denierten und von Auen ersichtlichen Fokus von schlechtem Code. Undurchdachter oder unter Zeitdruck niedergeschriebener Quelltext versucht oft mehrere Aufgaben auf einmal zu erfllen, wodurch er nicht in der Lage ist seiu nen Auftrag klar zu kommunizieren, was auf diese Weise Ausdruckskraft, Kontrolle und Erweiterbarkeit vermindert beziehungsweise erschwert [8]. Auf Basis dieser Feststellung lassen sich verschiedene Unterscheidungskriterien formulieren, von denen Folgende im Bezug auf TDD von Interesse sein werden: Lesbarkeit - Wie gut lsst sich der Code von anderen a EntwicklerInnen nachvollziehen? Testbarkeit - Inwiefern ist der Code fr automatisieru tes Testen geeignet und vorbereitet? Anderbarkeit - Wie leicht macht der Code es anderen ProgrammierInnen ihn zu erweitern? Zwar handelt es sich hierbei um keine objektiv messbaren Kriterien, dennoch lassen sich unterschiedliche Quelltexte mit Hilfe dieser drei Qualittsmerkmale unterscheidend bea werten und als Grundlage fr die nachfolgende Analyse der u

Auf Basis der Ergebnisse dieser Auswertungen wird im Folgenden untersucht, welche Auswirkungen testgetriebene Entwicklung auf die Code-Qualitt hat und ob sich unter ina tensiver Verwendung von TDD auf diese Weise auch die Software-Qualitt im Allgemeinen verbessern liee. a

4.

TESTGETRIEBENE ENTWICKLUNG

Als testgetriebene Entwicklung wird eine qualittsbewusste a Programmiertechnik beschrieben, die es ermglicht, Softwao re dem agilen Manifest folgend, iterativ, in kleinen Schritten zu entwickeln. Die Besonderheit und gleichzeitig das Unterscheidungsmerkmal zu anderen Anstzen oder dem klassia schen Vorgehen besteht darin, dass bei der testgetriebene Entwicklung automatisierte Unit-Tests1 intensive Verwendung nden, die als explizite Anforderungen an den Code auftreten und es nicht nur ermglichen Software in kleinen, o ubersichtlichen Einheiten zu prfen, sondern die Programu miererInnen auf gleiche Weise bei der korrekten Entwicklung zu untersttzen. Weiterhin ermglichen automatisierte u o Akzeptanztests auch die Anforderungen des Kunden an das komplette Produkt testbar zu machen, indem sie ein Programm als integrierte Einheit betrachten [11].
1 Unit-Tests uberprfen in der Regel jeweils nur wenige Zeiu len Quellcode (der Unit) [6]. Programmbibliotheken wie JUnit fr Java, NUnit fr .Net oder hnliche Portierungen lieu u a fern dafr notwendige Programmbausteine und ermglichen u o als quelloene Bibliotheken Tests ohne proprietre Werkzeua ge zu entwickeln.

4.1

Die Gesetze der TDD

auftretende Fehler zeitnah zu reagieren.

Die Leitidee des testgetriebenen Vorgehens ist das sogenannte Tests-First-Denken. Ziel dabei ist es bereits vor der Implementierung des zu testenden Produktiv-Codes Testflle aufzustellen und darauf aufbauenden Testcode zu enta wickeln, der die Anforderungen an die zu programmierende Logik explizit deniert und die Korrektheit uberprft. Der u Tests-First-Ansatz basiert im wesentlichen auf folgenden drei Gesetzen [7]:

Erstes Gesetz - Schreiben sie erst Produktions-Code wenn sie einen scheiternden Unit-Test geschrieben haben. Zweites Gesetz - Der Unit-Test darf nicht mehr Code enthalten als fr ein Scheitern notwendig ist. Jeder u Test sollte genau eine Sache prfen. u Drittes Gesetz - Es darf nur so viel ProduktionsCode geschrieben werden, wie fr das Bestehen des u Tests ntig ist. o

Im Gegensatz zu klassischen Software-Entwicklungsprozessen wie dem Wasserfall- oder V-Modell (als Extrembeispiele), die eine sogenannte Test-Phase oft an das Ende ihrer Prozesskette hngen, ermglicht TDD Tests zeitnah zur eia o gentlichen Programmierung zu erstellen und sorgt somit dafr, dass diese nicht unter Zeitdruck wegrationalisiert weru den. Zudem fhren die automatisierte Wiederholbarkeit und u das durch die Gesetze der TDD implizit notwendige huge a Kompilieren des Quellcodes nicht nur dazu, dass Tests selbst unter Zeitdruck ausgefhrt werden knnen sondern ermgu o o lichen auch das Erkennen von Fehlern und Seiteneekten gleich bei ihrer Entstehung [11]. Ein eektives Testen ist die Folge.

Der daraus resultierende Workow entspricht folglich einem Kreislauf der mit dem Schreiben eines Tests beginnt (Phase 1). Durch das Testen von Funktionalitt die (noch) nicht a vorhanden ist, wird in Folge dessen ein Fehler im System erzeugt, der anschlieend durch das Erstellen des eigentlichen Programm-Codes behoben wird (Phase 2). Whrend des aba schlieenden, sogenannten Refactorings (Phase 3) werden Code-Duplizierung entfernt, eventuell notwendige Abstraktionen eingefgt, Code-Smells2 beseitigt, gngige Style-Konu a ventionen umgesetzt und der Code so in seine (temporr) a einfachste Form gebracht [9]. Damit einher geht ferner die Notwendigkeit eines evolutionren Designs welches den agia len Charakter von TDD ein weiteres Mal unterstreicht. So wird das Design der Software nicht im Voraus und in seiner Detailiertheit geplant, viel eher kommt es im Laufe der Entwicklung zu (temporren) Design-Entscheidungen die sich a im Wesentlichen auf die vordenierten Testflle sttzen und a u somit, wie auch die Code-Entwicklung, einem iterativen Prozess untergeordnet sind.

Testgetriebene Entwicklung versetzt EntwicklerInnen demnach auf der einen Seite in die Lage mit Hilfe von automatisierten Tests vom Beginn der Programmierarbeit an die funktionale Qualitt der Software zu bewahren und gestata tet es durch fortlaufendes Refactoring zudem auch die strukturelle Qualitt zu erhalten [11]. Beides fhrt zwangslug a u a zu einem Mehr an Code-Qualitt (siehe Abschnitt 2): a Hohe Anderbarkeit - Dadurch, dass uberwiegend nur Code im Einsatz ist, der zuvor mit Tests abgedeckt wurde, wird die vorhandene Funktionalitt zu jeder a Zeit, also auch bei Erweiterung und Uberarbeitung, abgesichert. Hohe Testbarkeit - Dadurch, dass der ProduktivCode sozusagen als Antwort auf die zuvor formulierten Tests verfasst wurde, handelt es sich bei ihm um vom logischen und strukturellen Aufbau her um besonders testbaren Code. Hohe Lesbarkeit - Aufgrund des stndigen Refactoa rings unterliegt der Quellcode einer stndigen Evolua tion deren Ziel es ist in aussagekrftigen, lesbaren Coa de zu mnden. Unverstndliche Passagen lassen sich u a zudem hug mit Hilfe der gezielt formulierten Tests a erschlieen.

Auf diese Weise existiert im Idealfall zu jeder Zeit der Software-Entwicklung nur so viel Code wie unbedingt ntig, der o zudem in hohem Mae mit Testfllen abgedeckt ist und soa mit nicht nur ausschlielich seine Anforderungen erfllt (das u tut was er soll), sondern auch ubersichtlich und nachvollzieh bar bleibt. Den EntwicklerInnen wird so ermglicht einen o exakten Uberblick uber die Korrektheit des (beinahe gesam ten3 ) Programm-Codes erhalten zu knnen, was sie wiedero um befhigt, untersttzt durch die automatisiert laufenden a u Tests, Bugs und Probleme bereits whrend der Entwicklung a erkennen zu knnen und des Weiteren verpichtet auf diese o
2 Code-Smells, also schlechte Code-Gerche, bezeichnen subu jektive Indizien fr schlechten Code, denen in der Regel ein u tiefer liegendes Problem im System zugrunde liegt [11]. 3 Je nach Programm und Programmiersprache unterscheidet sich der Umfang der eektiv zu erreichenden Testabdeckung. Eine hundertprozentige Testabdeckung wird nur in Ausnahmefllen erreicht und ist aufgrund des relativ groen a Overheads nur bedingt erstrebenswert.

5.

FAZIT

Wie in den vorangegangenen Abschnitten gezeigt wurde, kann die testgetriebene Software-Entwicklung zu einem Mehr an Code-Qualitt beitragen. Indem sie nicht nur die funka tionale sondern auch die strukturelle Qualitt einer Software a mageblich prgt und durch die intensive Ausrichtung auf a das Erstellen von Unit-Tests bewahrt, fhrt sie zu Software, u die sich durch eine hohe Erweiter- und Anderbarkeit, Testbarkeit sowie Lesbarkeit auszeichnet. TDD ist somit nicht nur geeignet, durch sein iteratives Vorgehensmodell einer unzureichenden organisatorischen Verankerung und einem geringen Automatisierungsgrad des Testens entgegen zu wirken, sondern lsst es durch die aktive Einbindung der Enta wicklerInnen in den Testprozess auch zu, eine mangelnde Abstimmung zwischen Anwendungsentwicklern und Testern vorzubeugen (vgl. Abschnitt 3).

Durch das enge Zusammenspiel von automatisierten Tests, Produktionscode und evolutionrem Design auf Basis der gea forderten Test-Code-Refactoring-Zyklen kann testgetrie bene Entwicklung zu einer methodischen Entwicklungsweise, mit iterativem Programmierfortschritt und sauberem Code fhren [11] - einen disziplinierten Umgang, Interesse und u Spa am agilen Entwickeln vorausgesetzt.

6.

LITERATURVERZEICHNIS

[1] Erfolgreiche Software-Projekte durch Software Quality Assurance - Software-Entwicklung und Software-Testing in Deutschland 2012. IDC Central Europe GmbH, 2012. http://goo.gl/ZZZgW. [2] W. Achtert, T. Becker, H. Biskup, D. Hellebrand, J. Herczeg, S. Krause, M. Kuhrmann, F. Maar, F. Marschall, M. Minich, F. Simon, and S. Ziegler. Industrielle Softwareentwicklung - Leitfaden und Orientierungshilfe. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V., 2010. http://goo.gl/9Nmv2. [3] H. Balzert. Lehrbuch der Softwaretechnik, Teil 2: Softwaremanagement, Software-Qualittssicherung, a Unternehmensmodellierung. Spektrum-Akademischer Verlag, 1998. [4] K. Beck and C. Andres. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional, 2004. [5] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas. Manifesto for Agile Software Development. The Agile Alliance, 2001. [6] S. Kbeck. Software-Sanierung - Weiterentwicklung, u Testen und Refactoring bestehender Software. mitp Verlag, 2009. [7] R. C. Martin. Professionalism and Test-Driven Development. IEEE Computer Society Press, 2007. [8] R. C. Martin. Clean Code - Refactoring, Patterns, Testen und Techniken fr sauberen Code. mitp Verlag, u 2009. [9] D. Pilone and R. Miles. Softwareentwicklung von Kopf bis Fu. OReilly Verlag, 2008. [10] C. Settgast. Agile Softwareentwicklung im Forschungsumfeld. 2010. http://goo.gl/7AOvq. [11] F. Westphal. Testgetriebene Entwicklung mit JUnit & FIT - Wie Software nderbar bleibt. dpunkt Verlag, a 2006.