Hallo Spa\u00df Coder,<\/p>\n
nachdem wir\u00a0in den letzten Artikeln unserer Serie schon einiges zum Thema Testautomatisierung<\/a> im allgemeinen und Unit-Tests<\/a> im speziellen gelernt haben, m\u00f6chten wir heute auf eine besondere Technik\u00a0automatisierter Tests eingehen.<\/p>\n <\/p>\n Beim Test-Driven-Development (abgek\u00fcrzt TDD) geht es darum,\u00a0den automatisierten Test in den Mittelpunkt der Entwicklung zu stellen. Entstanden ist die Idee von Kent Beck,\u00a0der insbesondere Unit-Tests damit im Blick hatte.\u00a0Das Ziel dabei ist es, den Code in kleinen Iterationen zu entwickeln, wobei der Code bei jedem Zyklus folgende\u00a0Stufen durchl\u00e4uft:<\/p>\n Diese Zyklen werden so lange mit allen Anforderungen wiederholt, bis die gew\u00fcnschte Funktion vollst\u00e4ndig implementiert ist.<\/p>\n Kent Beck nennt diesen Zyklus Red<\/span>–Green<\/span>–Refactor<\/span>. Zuerst wird ein Unit-Test geschrieben der fehlschl\u00e4gt, also in der IDE rot<\/span> dargestellt wird. Anschlie\u00dfend wird die Funktion soweit implementiert, dass der Test nicht mehr fehlschl\u00e4gt und somit in der IDE gr\u00fcn <\/span>dargestellt wird. Ist die Implementierung des Produktionscodes abgeschlossen, wird ein Refactoring <\/span>durchgef\u00fchrt, um auch die Qualit\u00e4t des Codes hoch zu halten.<\/p>\n Voraussetzung f\u00fcr den Zyklus ist, dass die wesentlichen Akzeptanztests bereits vor dem Start der Entwicklung formuliert sind.<\/p>\n <\/p>\n Martin Fowler macht noch mal sehr deutlich, dass ich als Entwickler in diesem Zyklus zwei verschiedene Perspektiven einnehme, wenn ich Code \u00e4ndere. Martin hat dies anhand von zwei H\u00fcten beschrieben, die ich nacheinander aufsetze. Einerseits implementiere ich die Anforderung und entwickle den Algorithmus oder die Fachlogik. Eben genau so lange, bis meine Tests (wieder) gr\u00fcn<\/span> sind. Hierbei erg\u00e4nze ich eine Funktion und trage den ersten Hut. F\u00fcr das Refactoring<\/span> wechsle ich nun meinen Hut und schaue konzentriert auf die Codestruktur mit der expliziten Absicht, die Funktionsweise des Codes nicht<\/strong> zu ver\u00e4ndern. Die Tests geben mir dabei Feedback, dieses im Blick zu halten. Solange diese gr\u00fcn<\/span> bleiben, habe ich keine (bisher getestete) Funktionsweise ver\u00e4ndert.<\/p>\n Die Idee bei dieser Symbolik ist, dass ich die beiden H\u00fcte nie gleichzeitig aufsetzen kann und daher ganz bewusst den Hut (die Perspektive) wechsle, wenn ich im Code arbeite – entweder Funktionen erg\u00e4nzen oder den Code umstrukturieren. Diese strikte Trennung unterst\u00fctzt eine strukturierte Arbeitsweise, so dass ich nicht zu viele Dinge auf einmal mache.<\/p>\n <\/p>\n Durch den einfachen Zyklus von Kent Beck erreichen wir Vieles, was auf den ersten Blick nicht ersichtlich wird.<\/p>\n Sicherstellen von\u00a0Akzeptanzkriterien, statt pr\u00fcfen\u00a0einer Funktion<\/strong><\/p>\n Neben der offensichtlichen Tatsache, dass wir zu jedem unserer Anwendungsf\u00e4lle nach Abschluss der Entwicklung einen Unit-Test haben, sind diese Tests auch relevant. Sie pr\u00fcfen\u00a0nicht eine Funktion, die wir implementiert haben. Vielmehr stellt ein\u00a0so erstellter Test sicher, dass ein durch den Anforderer formuliertes Akzeptanzkriterium erf\u00fcllt wird. Dies erh\u00f6ht deutlich die Qualit\u00e4t des Tests an sich.<\/p>\n <\/p>\n Sauberes Interface implementieren<\/strong><\/p>\n Wenn wir zuerst\u00a0den Test schreiben, bevor wir mit der Implementierung des Produktionscodes beginnen,\u00a0werfen wir als Entwickler einen ganz anderen Blick auf die Aufgabenstellung. So schauen wir beim Schreiben von Tests aus Sicht des Aufrufers auf unsere Klasse. Wir \u00fcberlegen uns also: „Wie w\u00fcrde ich diese Klasse verwenden wollen?“ Daraus ergibt sich fr\u00fch ein sauberes Interface der Methoden der Klasse, noch bevor auch nur eine Zeile Produktionscode geschrieben ist:<\/p>\n All diese Fragen stellen wir uns typischerweise nicht, wenn wir gleich mit der Implementierung beginnen.<\/p>\n <\/p>\n Fokussieren auf die Anforderung<\/strong><\/p>\n Ein anderer Aspekt ist die Fokussierung auf die Anforderung. Fangen wir gleich mit dem Produktionscode an, vergraben wir uns oft\u00a0schnell in Details zur Probleml\u00f6sung.\u00a0Dar\u00fcber hinaus versuchen wir die Anforderung h\u00e4ufig gleich ganzheitlich zu l\u00f6sen. Gehen wir stattdessen von den Akzeptanztests aus, erf\u00fcllen\u00a0wir immer genau nur eine Anforderung nach der anderen, l\u00f6sen\u00a0einen Akzeptanztest nach dem anderen.<\/p>\n <\/p>\n Refactoring in Fleisch und Blut<\/strong><\/p>\n Das\u00a0Refaktorisieren ist fester Bestandteil\u00a0im\u00a0o.g. Zyklus. Verfolgen wir diesen fokussieren Ansatz, haben wir jeden Teil unseres Produktionscodes nicht nur getestet, sondern hinterlassen den Code auch sofort sauber und ordentlich. Wir erstellen nicht erst einen riesigen Berg Produktionscode, den wir dann nochmal aufr\u00e4umen m\u00fcssen, sondern sorgen\u00a0w\u00e4hrend der gesamten Implementierungsphase f\u00fcr sauberen, gut strukturierten Code.<\/p>\n Sollte es durch eine sp\u00e4ter umgesetzte Anforderung notwendig werden, vorherige Teile neu zu implementieren, ist dieser so gut strukturiert, dass er sich\u00a0leicht umstellen l\u00e4sst…und getestet ist er ja auch, also Angst vor der Umstellung brauchen wir auch nicht zu haben.<\/p>\n <\/p>\n Viele kleine Belohnungen<\/strong><\/p>\n Durch den Zyklus Red<\/span>–Green<\/span>–Refactor<\/span> erfahren wir regelm\u00e4\u00dfig Belohnungen. Der Test ist gr\u00fcn? Cool, wieder was geschafft! Der Code ist sauber refaktorisiert? Klasse, ein Akzeptanzkriterium umgesetzt, auf zum n\u00e4chsten!<\/p>\n Auch wenn dieser Vorteil eher unwichtig klingt, ist er doch nicht zu vernachl\u00e4ssigen. Je besser wir „drauf“ sind, desto besser ist unsere L\u00f6sung und desto sauberer wird unser Code.<\/p>\n <\/p>\n Kosten<\/strong><\/p>\n Auch wenn es sich in er Erz\u00e4hlung einfach anh\u00f6rt, ist eine Eingew\u00f6hnung in das Thema wichtig. Wir\u00a0erl\u00e4utern das sp\u00e4ter nochmal bei unseren Erfahrungen. F\u00fcr ein erfolgreiches\u00a0Test-Driven-Development\u00a0ist also noch mehr Investition notwendig, als ohnehin schon f\u00fcr die Testautomatisierung<\/a>.<\/p>\n <\/p>\n Akzeptanzkriterien erforderlich<\/strong><\/p>\n TDD funktioniert nur dann, wenn die Akzeptanzkriterien der Anforderung bekannt sind. Nur dann k\u00f6nnen wir die richtigen Tests formulieren und implementieren. Manchmal k\u00f6nnen wir uns selbst im Vorfeld welche \u00fcberlegen, wenn sie nicht im Rahmen\u00a0der Anforderung formuliert wurden.\u00a0Immer dann aber, wenn wir gar nicht so genau wissen, was wir erreichen wollen, funktioniert TDD nicht gut. Das ist in der Regel immer dann der Fall, wenn wir was ausprobieren wollen, wenn wir experimentieren.<\/span><\/p>\n <\/p>\n Ganz ehrlich? Test-Driven-Development f\u00fchlt sich komisch an. Einen Test schreiben f\u00fcr Code, den wir noch gar nicht haben? Das geht doch gar nicht! Das war meine (Torsten) erste Reaktion auf das Verfahren. Auch sp\u00e4ter, nachdem ich es einmal ausprobiert hatte, fand ich das Vorgehen irgendwie doof. Ich bin immer wieder in alte\u00a0Verhaltensweisen verfallen. Lieber erst mal den Code schreiben und dann schauen, was man testen kann.<\/p>\nTest-Driven-Development<\/h1>\n
\n
Bewusster Perspektiven-Wechsel<\/h3>\n
Was spricht f\u00fcr TDD?<\/h1>\n
\n
Was spricht gegen\u00a0TDD?<\/h1>\n
Unsere Erfahrung mit TDD<\/h1>\n