Page tree
Skip to end of metadata
Go to start of metadata

Einleitung

Software muss getestet werden. Es gibt sogar im Software-Entwicklungsprozess eine eigene Phase dafür. Die Frage "dass" getestet werden muss steht nicht im Raum, das "wie" erregt die Gemüter. Jede Entwicklerin und jeder Entwickler testet - irgendwie. Meist sind die Tests ohne es zu wissen Integrationstests. Der Debugger wird angeschmissen und von der Oberfläche heraus oder auch über XML-Testtools werden die Controller durchlaufen und dann bis in die niederen Schichten herunter gedebugged. Integrationstests sind jedoch 10 Mal so teuer wie ein Unit-Test. Wenn Entwickler den ganzen Tag Integrationstest durchführen, verbrennen sie Geld.

These: Keine Unit-Tests zu schreiben verzögert das Projekt und verbrennt Geld.

Hauptprobleme von Integrationstests und Debugging

Integrationstests sind teuer, sehr aufwändig zu implementieren und schwer zu warten. Ein Integrationstest als Debugsession ist zudem nicht nachhaltig. Von daher ist es vollständig unverständlich, warum die Zeit mit Degugging verplempert wird, statt gute Unit-Tests zu schreiben.

These: Eine 100% Testabdeckung macht viele Integrationstests obsolet, weil die meisten Fälle bereits getestet sind.

A. Integrationstests durch Debuggen sind nicht nachhaltig

Diese Art des testens ist nicht nachhaltig. Ist ein Bereich bereinigt bzw. der Bug gefixt und tritt ein weitere Bug in dem gleichen Bereich auf, dann muss von vorne angefangen werden (don't repeat yourself). Tatsächlich ist es so, dass nicht erkannt wird, wenn der gleich Bug noch einmal auftritt. Dass ein Bug noch einmal auftritt ist in Zeiten von Branching und Merging gar nicht so selten, vor allem wenn die Konfliktbereinigung nicht sauber durchgeführt wird.

B. Integrationstests sind teuer.

Debuggen ist sehr zeitaufwändig. Außerdem braucht es viel Zeit einen Fehler tatsächlich auch als Fehler zu erkennen. Oft wird wieder und immer wieder über den Code gedebugged, bevor der Fehler überhaupt erkannt wird. Man geht davon aus, dass ein Fehler von den Kosten her sich verzehntfacht, wenn er in nachfolgenden Zyklen erkannt wird. Am teuersten sind demnach Fehler, die erst nach Produktionsgang auftreten.

C. Integrationstests sind aufwändig und schwer automatisierbar

Integrationstest, die von der Oberfläche heraus die gesamte Anwendung durchlaufen sind sehr auffwändig. Das gilt nicht nur für die Entwicklung sondern vor allen für die Wartung.Teilweise laufen Oberflächentests nicht mehr, wenn ein Button auf der Oberfläche verschoben wird. Zweitens testen Integrationstest oft schon bereits durch Unit-Test getestete Pfade.

Die 3 Unwahrheiten über JUnit Tests

Unit-Test sind das Mittel der Wahl. Leider höre ich immer Dinge über JUnit Tests, die meinen Erfahrungen vollständig widersprechen.

1. Mit Unit-Tests verdoppelt sich der Code und damit der Implementierungsaufwand

Wer nachzählt hat Recht. Aber: Ist es nicht die originäre Aufgabe einer Programmiererin oder eines Programmierers Code zu schreiben? Ist es nicht einfacher den Test als Code zu schreiben als mit anderen Tools? Quantität ist nur ein Argument. Qualität ist wichtig. Testgetriebener Code produziert weniger Fehler. Und: Niemand produziert Code und checkt ihn ungetestet ein. Unit-Tests sind nachhaltig und verhindern, dass Entwicklerinnen und Entwickler händische Integrationstests über Debugsessions durchführen. Somit sind sie in Summe günstiger.

2. Mit Unit-Tests kann man nicht alles testen

Eine Oberfläche ist über Unit-Tests schwer testbar. Aber alles was in den unteren Schichten stattfindet (Controller, Facade, Service, DAO, Entität, DTO ...) sehr wohl. Und ganz ehrlich: Wenn die Funktionalität bis zum Controller getestet wurde, sind die letzten Schritte nicht geschenkt aber nicht mehr so wichtig. Die Testpyramide von Martin Fowler zeigt ganz deutlich: Wichtig sind Tests auf Unit-Ebene. Die Testabdeckung in höheren Schichten, wie bei der GUI, sind sehr aufwändig, haben einen hohen Wartungsaufwand und nicht den hohen Effekt, welche Unit-Tests haben.

3. Mit Unit-Tests wird der Code nicht "tief" genug getestet

Das alleine hängt von den Tests ab. Wenn die Tests nicht nur eine Code-Coverage von 100% haben sondern auch eine Mutation-Coverage von 100% sind sie gut und nützlich. Wer natürlich sein Projekt nach Indien gibt um die Tests nachzuziehen (kein Scherz, das habe ich im wahren Leben schon erlebt) muss sich nicht wundern, wenn die Tests zwar den Code vollständig abdecken, aber ansonsten Makulatur sind. Sie können ja nur noch das abbilden, was sowieso schon im Code vorhanden ist.

Test First führt zu besserem Code

Forschungen von einigen Entwicklerinnen und Entwickler zeigen: Testgetriebene Entwicklung führt unweigerlich zu einer sehr guten Testabdeckung aber: Die Qualität der Tests und des Codes ist deutlich besser, als bei Tests, die im nachhinein geschrieben werden.

 

 

 

 

 

  • No labels