Test Driven De­ve­lo­p­ment: So funk­tio­niert die Methode

Mit stei­gen­der Kom­ple­xi­tät von Com­pu­ter­pro­gram­men werden auch die agilen Methoden des Test Driven De­ve­lo­p­ments (TDD) immer beliebter. Und das aus gutem Grund: Mit TDD sorgen Pro­gram­mie­rer dafür, dass das Design einer Software auch gut durch­dacht ist, bevor sie sich ans Schreiben des Funk­ti­ons­codes machen. Diese Vor­ge­hens­wei­se erhöht nicht nur die Qualität der Software maß­geb­lich, sondern reduziert auch den War­tungs­auf­wand.

Die test­ge­trie­be­ne Ent­wick­lung kommt u. a. im Extreme Pro­gramming zum Einsatz, das sich durch fort­lau­fen­de Reviews, Tests, Design und Redesign aus­zeich­net. Auch das Test Driven De­ve­lo­p­ment hält sich an einen Ent­wick­lungs­zy­klus, dessen Rei­hen­fol­ge für eine effektive Umsetzung ein­ge­hal­ten werden muss.

Ver­schie­de­ne Test­me­tho­den, die die Qualität einer Software kon­trol­lie­ren, gibt es schon lange. Bereits zu Beginn der Software-Ent­wick­lung über­prüf­ten un­ab­hän­gi­ge Tester Com­pu­ter­pro­gram­me im Qua­li­täts­ma­nage­ment auf ihre Funk­tio­na­li­tät. Die ei­gent­li­che Ent­wick­lung der Software und die Test­ver­fah­ren wurden damals noch als un­ab­hän­gi­ge Prozesse angesehen. Erst mit dem US-ame­ri­ka­ni­schen Software-Ent­wick­ler und Begründer des Extreme Pro­grammings Kent Beck entstand der Test-First-Ansatz. Dieser hat den bis­he­ri­gen Ablauf einfach umgekehrt: Anstatt erst den Quellcode zu schreiben und diesen dann zu testen, schreibt das Ent­wick­ler­team erst die Tests. Dann verwendet es die Testfälle, um den best­mög­li­chen Code zu schreiben und zu im­ple­men­tie­ren.

Auch wenn die test­ge­trie­be­ne Ent­wick­lung einem Laien zunächst kon­train­tui­tiv erscheint, hat sie durchaus ihren Sinn und führt zu besseren Er­geb­nis­sen. Während bei her­kömm­li­chen, nach­ge­schal­te­ten Test­ver­fah­ren ein Was­ser­fall­mo­dell oder V-Modell ein­ge­setzt wird, verlaufen die Prozesse beim TDD nämlich in einem Zyklus. Das heißt, dass Sie zuerst Testfälle bestimmen, die häufig fehl­schla­gen. Dies geschieht mit Absicht, denn im zweiten Schritt verfassen Sie nur so viel Code, wie für das Bestehen der Tests benötigt wird. Daraufhin werden die Kom­po­nen­ten re­fak­to­ri­siert: Unter Bei­be­hal­tung seiner Funk­tio­nen erweitern Sie den Quellcode oder struk­tu­rie­ren ihn falls nötig um.

Das Test Driven De­ve­lo­p­ment ori­en­tiert sich an den Er­geb­nis­sen der von Ihnen be­stimm­ten Testfälle. Die zyklische Ver­fah­rens­wei­se stellt sicher, dass der Code erst ins Pro­duk­tiv­sys­tem über­tra­gen wird, wenn alle An­for­de­run­gen an die Software erfüllt sind. Das heißt, dass Sie die Code­be­stand­tei­le so oft re­fak­to­ri­sie­ren und neu testen, bis der Test nicht mehr als feh­ler­haft angezeigt wird. Durch diese Methode reichern Sie die Software schritt­wei­se mit neuen Funk­tio­nen an, da Sie nach jedem be­stan­de­nen Test einen neuen Quellcode verfassen. Aus diesem Grund zählt TDD auch zu den in­kre­men­tel­len Vor­ge­hens­mo­del­len in der Software-Ent­wick­lung.

Einzelne Testfälle durch­lau­fen den Zyklus in der Regel nicht länger als ein paar Sekunden oder Minuten. So machen sich die Resultate schnell im Pro­duk­tiv­code bemerkbar. Damit die Iteration ohne zu­sätz­li­chen Aufwand geschieht, brauchen Sie ein TDD-Werkzeug und -Framework. Ty­pi­scher­wei­se verwenden Ent­wick­ler ein Tool zur Build-Au­to­ma­ti­sie­rung wie Crui­se­Con­trol oder Jenkins. Diese erlauben die kon­ti­nu­ier­li­che und feh­ler­freie In­te­gra­ti­on von Kom­po­nen­ten in den Quellcode. Beliebt bei der Java-Ent­wick­lung sind auch JUnit, Maven oder Ant. Generell gilt: Die Tests werden immer in der gleichen Sprache wie der Funk­ti­ons­code ge­schrie­ben. Für PHP gibt es u. a. die Werkzeuge Ceedling oder CMock.

Aber wie läuft das Test­ver­fah­ren genau ab? Der Zyklus, dem Pro­gram­mie­rer im Test Driven De­ve­lo­p­ment folgen, wird auch Red-Green-Refactor-Zyklus genannt. Dieser be­schreibt die einzelnen Phasen, die Sie für maximale Effizienz durch­lau­fen:

1. Rote Phase: In dieser Phase denken Sie sich in die Rolle des Nutzers hinein. Dieser möchte den Code auf einfache Weise verwenden. Sie schreiben also einen Test, der Kom­po­nen­ten enthält, die noch nicht im­ple­men­tiert wurden. So müssen Sie eine Ent­schei­dung darüber treffen, welche Elemente für das Funk­tio­nie­ren eines Codes wirklich notwendig sind.
2. Grüne Phase: An­ge­nom­men, der Test schlägt fehl und wird rot markiert. Nun nehmen Sie die Rolle eines Pro­gram­mie­rers ein, der versucht, eine simple Lösung zu finden. Wichtig: Sie schreiben nur so viel Code wie nötig. Diesen in­te­grie­ren Sie in den Pro­duk­tiv­code, sodass der Test mit grün markiert wird.
3. Re­fac­to­ring: In diesem Schritt wird der Pro­duk­tiv­code re­gel­recht „auf­ge­räumt“ und in seiner Struktur per­fek­tio­niert. Das heißt, Sie sollten ihn ergänzen und so um­struk­tu­rie­ren, dass er aus Ent­wick­ler­sicht elegant und ver­ständ­lich ist. Entfernen Sie z. B. Code-Du­pli­zie­run­gen und bringen Sie ihn so auf ein pro­fes­sio­nel­les Niveau.

Achten Sie darauf, dass sich die einzelnen Ak­ti­vi­tä­ten nicht über­schnei­den. Das heißt, dass Sie keine Tests in Phase 2 oder 3 und keinen Pro­duk­tiv­code in Phase 1 und 3 schreiben. Im folgenden Video sehen Sie, wie die test­ge­trie­be­ne Ent­wick­lung in der Praxis funk­tio­niert:

Test Driven De­ve­lo­p­ment ist eine De­sign­stra­te­gie, die den Ent­wick­lungs­pro­zess einer Software mittels ver­schie­de­ner Tests leitet. Im Gegensatz zu nach­ge­stell­ten Verfahren sind die Testfälle im TDD von Anfang an Teil des Software-Designs. Dabei un­ter­schei­den sich die Tests, die im Rahmen von TDD ein­ge­setzt werden, in Zweck und Umfang. Der ein­fachs­te Test ist der Modultest oder Unit-Test. Mit diesem werden einzelne Kom­po­nen­ten eines Com­pu­ter­pro­gramms getestet. Komplexer sind die In­te­gra­ti­ons- und Funk­ti­ons­tests, mit denen Sie das Zu­sam­men­spiel ver­schie­de­ner Sys­tem­tei­le und die Ge­samt­funk­tio­na­li­tät einer Software über­prü­fen.

Aus dem TDD ent­wi­ckel­te sich vor einigen Jahren das Behavior Driven De­ve­lo­p­ment (BDD), auch ver­hal­tens­ge­trie­be­ne Software-Ent­wick­lung genannt. Bei dieser kon­zen­triert sich ein Ent­wick­ler­team zunächst nicht auf die Rich­tig­keit des Codes, sondern auf die ge­wünsch­te Ver­hal­tens­wei­se der Software. Der Vorteil ist hier, dass Sie für das Schreiben der Testfälle kein tech­ni­sches Code­ver­ständ­nis haben müssen und so Stake­hol­der und Qua­li­täts­ma­na­ger in die Ent­wick­lung mit­ein­bin­den können. Generell lässt sich sagen, dass BDD die beste Vor­ge­hens­wei­se beim Schreiben von Tests festlegt, während TDD für eine saubere Ar­chi­tek­tur sorgt.

In der folgenden Tabelle sind die Vor- und Nachteile der test­ge­trie­be­nen Ent­wick­lung kurz zu­sam­men­ge­fasst:

Obwohl Sie die ver­schie­de­nen Test­ver­fah­ren auch einzeln anwenden können, erhalten Sie mit einer Kom­bi­na­ti­on aus test- und ver­hal­tens­ge­trie­be­nen Ent­wick­lungs­me­tho­den eine hoch­wer­ti­ge­re Software. Diese bereitet auch dem Endnutzer mehr Freude.