Test Driven Development (Teil 3 von 3)
Nach den Grundlagen und einem wilden Beispiel findet der TDD-Dreiteiler hier seinen Abschluss. Um reinzukommen, hier nochmal der aktuelle, fertige Stand in Gänze:
- import static org.hamcrest.CoreMatchers.is;
- import static org.junit.Assert.assertThat;
- import org.junit.Test;
- public class AdditionTest {
- @Test
- public void testOnePlusOneIsTwo() {
- assertThat(add(1, 1), is(2));
- }
- @Test
- public void testOnePlusTwoIsThree() {
- assertThat(add(1, 2), is(3));
- }
- @Test
- public void testTwoPlusTwoIsFour() {
- assertThat(add(2, 2), is(4));
- }
- private int add(int a, int b) {
- return a + b;
- }
- }
genug ist genug ist genug
Einen weiteren Testfall zu schreiben, lohnt zu diesem Zeitpunkt nicht mehr: Von Integer-Overflows mal abgesehen kriegen wir den Code nicht mehr kaputt. Einen Test hinzuschreiben, der von Anfang an grün ist, bringt nichts (wir erinnern uns: ein neuer Test soll initial immer rot sein). Nach der reinen Lehre wird ein neuer, sofort grüner Test auch sofort wieder gelöscht.
(Mit dieser Regel habe ich in der täglichen Arbeit manchmal noch Probleme. Es gibt manchmal ein, zwei wichtige Konstellationen, die ich ganz sicher abprüfen möchte, auch wenn meine Implementierung zufällig auf Anhieb so korrekt war, dass ich während der Entwicklung keinen passenden fehlschlagenden Test konstruieren konnte. Letztendlich ist bei dem strengen Vorgehen das Erlaubt-Sein eines einzelnen Testfalles davon abhängig, wie die Zwischenschritte auf dem Weg zum fertigen Code waren. Programmiert man linksrum, ist man an dem Testfall vorbeibekommen, programmiert man rechtsrum, kann der Fall nie rot gewesen sein – obwohl beide Male der gleiche Code entstanden ist. Das klingt mir schon sehr übertrieben-verkopft. Also schreibe ich durchaus mal eine „unerlaubte“ zusätzliche Testkonstellation. Dann kann ich nämlich ruhig schlafen und muss keine Angst haben, dass jemand später was ändert, was dann genau den wichtigen Fall kaputtmacht. Das geht aber auch schon ein wenig in Richtung Akzeptanztest. Bezogen auf das obige Codebeispiel: Da ich ja argumentiert hatte „Null = neutrales Additionselement = Sonderfall“, wäre ein Testfall mit 0 vielleicht ein solcher Absicherungstest, den ich noch ergänzen würde.)
Mein Fazit
Ich kenne TDD jetzt seit ca. einem halben Jahr. Am Anfang war das sehr ungewohnt und komisch. So habe ich die 25 Jahre vorher nicht programmiert. Es gefällt mir aber immer mehr und es lässt sich tatsächlich mit etwas Disziplin und Lust zum Ausprobieren auch in der täglichen Arbeit in echtem Code benutzen.
Die Zeit, die fürs Schreiben der Testfälle draufgeht, hat man wieder drin, wenn man den ersten Bug nicht suchen muss, weil man ihn schon beim Testen abgefangen hat. Oder wenn man zwei Stunden lang ungestört per TDD und Unit-Tests programmiert und dann zum Abschluss einmalig die Anwendung hochfährt und manuell testet anstatt wie früher alle drei Minuten das lokale Testsystem durchzustarten und sich erneut auf die Maske durchzuklicken, an der man gerade schraubt…
Ach ja: das geht nicht nur in Java, sondern mit jeder Sprache, in der man irgendwie Unit-Tests hinbekommt. Zur Not auch in Bash oder COBOL, wobei bei letzterem der Compile-Zyklus und die Jobausführung den TDD-Zyklus ziemlich schmerzhaft ausbremsen (zumindest wenn man „richtiges“ COBOL auf einem Großrechner macht, denn merke: COBOL ohne BUSINESS ist zwar COOL, aber nicht cool).
Try it!
IDE aufgemacht, neues Projekt angelegt, Test-Framework initialisiert und losgehackt: Beim Selbst-Ausprobieren kommt man am ehesten auf den Geschmack. Genau für so etwas sind Katas gedacht: Man könnte sich z.B. mal testgetrieben an der Simple Poker Hands Kata versuchen und beim ersten Mal ruhig etwas übertrieben kleinschrittig vorgehen so wie hier im Beispiel.
Oder man sucht sich eine Veranstaltung am Global Day of Coderetreat (Samstag, 22.10.2016; hierzulande häufig über die Softwerkskammer) irgendwo in seiner Nähe – da kann man das mal einen ganzen Tag lang live an einer interessanteren Aufgabe durchexerzieren, jeweils als Pair Programming mit wechselnden Teams und steigendem Schwierigkeitsgrad (Stichwort: Constraints, z.B. sind in einer Runde nur void-Methoden erlaubt). Geile Scheiße – mitmachen!
mitch
mitch am um :
Der erschien einen Tag vor meinem Blogartikel, da hätte ich mir das ja auch sparen können ;-) Immerhin bestätigt er mich inhaltlich. "Obvious Implementation" habe ich vergessen zu erwähnen, bei "Triangulation" laufen die Definitionen etwas auseinander, der Rest passt.
Was mich gerade überrascht: Der Autor des Artikels kommt von codecentric und dazu fällt mir sofort ein "hey, die waren auch auf der SoCraTes 2016" und "hey, die veranstalten den Global Day of Coderetreat in München (und sind gnadenlos überbucht").
Jue am um :
Zwei Fragen beschäftigen mich noch; und vielleicht kannst du diesen Knoten bei mir im Kopf lösen. Ich versuche es mal zu beschreiben:
1) Wie gehst du mit Abhängigkeiten um? Letztlich hat man zwischen den Klassen viele Abhängigkeiten: Klasse A nutzt Klasse B, die wieder Klasse C nutzt.
Ich bin jemand, der häufig bei C anfängt und sich dann zu A hocharbeitet. Zumindest wenn das Problem vorher schon gut überblickbar ist und ein grober Plan steht, wie ich mein großes Problem in kleine Teilprobleme aufspalte.
Schreibst du Mocks, die das Verhalten der Klassen mimen? Oder lässt du die Abhängigkeiten einfach bestehen und fängst mit den Tests bei A an und wenn keiner gegen die Wand fährt, testest du bei B weiter, das dann ein funktionierendes A voraussetzt?
2) Wie gehst du mit Abhängigkeiten zu externen Librarys um? Derzeit versuche ich (bzw. gerade ist das Projekt pausiert) einen Treiber für Mesh-Netzwerke zu schreiben. So richtige Unit-Tests habe ich dabei aber nicht geschrieben, da einfach sehr viel Logik in der TLS-Library steckt und ich keinen Nerv darauf hatte Netzwerkaktivitäten zu mocken. Zumal ich bezweifle, dass ich das Verhalten der TLS-Libaray ausreichend realitätnah nachgespielt bekomme. Mein Plan ist es, direkt einen Integration-Test zu schreiben, der mit Hilfe der Network-Namespaces von Linux verschiedene Netzteilenehmer simuliert. Somit bekommt jeder Node eine eigene IP und kann die anderen Nodes über eine Netzwerkbrücke sehen.
Ich hoffe, du verstehst was ich meine. Und vielleicht hast du eine Idee, wie ich das Problem löse.
LG Jue
mitch am um :
Zu 1:
Bei sehr einfachen Dingen benutze ich auch im Test echte andere Klassen: Hauptsächlich bei Datenobjekten/Beans, die nur aus Gettern/Settern bestehen und deshalb keinen eigenen Test bekommen. So kriegt man noch etwas Codeabdeckung hin (und erkennt überflüssige Attribute, wenn die Getter/Setter im Test nie aufgerufen werden).
Manchmal arbeite ich auch mit echten anderen Klassen, die ihrerseits keine weiteren Abhängigkeiten haben, wenn das an der Stelle einfacher/schneller/übersichtlicher als ein Mock oder Stub ist. Das verstößt aber bestimmt gegen irgendeine eine Form der Reinen Lehrte™.
Wenn ich aber eine Klasse A teste, die ihrerseits aber auf die Klassen B und C zugreift, die ihrerseits mit Instanzen der Klassen D, E und F versorgt werden wollen, damit es keine NullPointerExceptions gibt, dann hört für mich der Spaß auf und es wird gemockt oder gestubbt.
Zu 2:
Hmm, das hängt wohl von der Library ab…
Unser firmeninternes Framework ist in der aktuell noch genutzten Inkarnation nicht besonders Unit-Test-freudig, dafür habe ich mal einen Haufen Stubs geschrieben, die die Interfaces ghettomod-mäßig nachimplementieren (und auch nur jeweils genau die Funktionen, die mein Projekt benutzt). Das war zwar rückblickend etwas Aufwand, dafür sind wir aber auch testfähig.
Für Teile unserer Oberfläche nutzen wir Vaadin. Dem ist es recht egal, ob es auf einem echten Webserver oder lokal im Unit-Test läuft, da können wir einfach mit den echten Vaadin-Klassen testen und z.B. Buttons in einem Testfall fragen, ob sie gerade enabled oder visible sind.
Bei Deinem Fall weiß ich nicht, wie es da drumherum aussieht. Die Integrationstestfälle klingen auf jeden Fall schon mal interessant :-)
Eine ganze TLS-Library zu mocken klingt hingegen nicht so toll.
Das Wunderwaffenallheilmittel für „Test zu kompliziert“ scheint „zerteil Dein Testobjekt“ zu sein. Ich kenne da deine Architektur nicht, aber vielleicht kann man die TLS-Teile soweit rausoperieren, dass die nur in einer dünnen Wrapper-Schicht zwischen Deinem eigentlichen Code und der TLS-Library liegen. Dann musst Du nur noch die (hoffentlich wenigeren) Aufrufe in deine Wrapperschicht wegmocken.
Die Unit-Testfälle für die Wrapper-Schicht bleiben dabei u.U. genauso doof wie vorher (also weglassen ;-), aber Du hast kannst vielleicht die andere Hälfte Deines Codes testen. Wäre doch schon mal was.
Keine Ahnung, ob das für Dich passt, aber vielleicht geht das in die richtige Richtung.
so long
Mitch
Mitch’s Manga Blog am : Test Driven Development (Teil 2 von 3)