Was soll das? Man hat doch schon genug damit zu tun, den Code für die eigentliche Funktionalität des Programms zu schreiben und dann soll man auch noch Tests erstellen? Das kostet doch nur Zeit. Kann man die Tests nicht weglassen?
Klar, kann man die Tests weglassen, aber ich vermute, dass es sich in 95 % aller Fälle später rächt, dass die Tests fehlen. Bei Anwendungen, die etwas über das Niveau von „Hallo World“ hinausgehen und auch tatsächlich produktiv eingesetzt werden, gehören Softwaretests einfach dazu. Dagegen gibt es keine Argumente, aber gute Gründe, warum das so ist:
- Tests haben dokumentarischen Charakter, denn sie zeigen, wie ein bestimmter Teil einer Software zu verwenden ist. Liest sich eine andere Entwicklerin oder ein anderer Entwickler die Tests durch kann sie oder er schnell begreifen, welche Aufgabe eine jeweilige Funktion hat und wie man sie einsetzt. Auch man selbst erinnert sich nach relativ kurzer Zeit nicht mehr, warum man bestimmte Abschnitte auf diese Art programmiert hat. Schon nach wenigen Wochen oder Monaten erkennt man den eigenen Code nicht mehr wieder und fragt sich, was man sich wohl dabei gedacht hat. Hierbei sind Tests eine wunderbare Gedächtnisstütze.
- Tests machen Code lesbarer, denn damit sich eine Funktion einfach testen lässt, muss man sie auch so schreiben. Wir alle kennen das Prinzip der eindeutigen Verantwortlichkeit (Single Responsibility Principle) sowie weitere sinnvolle Vorgaben wie Don’t Repeat Yourself, Once and Only Once und Single Point of Truth. Allerdings halten wir uns im Eifer des Gefechts nicht immer an diese Ratschläge, so dass wir in der Konsequenz hin und wieder mit Methoden enden, die mehr als eine Sache machen und viel zu lang sind. Dies passiert so gut wie gar nicht, wenn man Tests zu den jeweiligen Methoden schreibt, denn die helfen einem dabei, sich zu disziplinieren.
- Tests machen Anwendungen robuster und flexibler, denn beim Ausarbeiten von Tests macht man sich Gedanken, welche Grenzfälle jenseits der offensichtlichen Möglichkeiten existieren, eine Methode zu verwenden. So kann man Fehler viel früher entdecken und je früher ein Problem erkannt wird, desto günstiger lässt sich ein derartiges Problem beheben. Hat man genügend Tests geschrieben, kann man zu einem späteren Zeitpunkt Teile des Programms ändern, ohne sich Sorgen zu machen, dass man wiederum andere Bereiche des Programms kaputt gemacht hat, weil man vergessen hat, dass es Abhängigkeiten zwischen den Teilen gibt.
- Tests zeugen von messbarer Qualität, denn es lässt sich bestimmen, wie groß die Testabdeckung (Code Coverage) innerhalb einer Klasse, eines Moduls oder des gesamten Programms ist. Diese in Prozent angegebene Zahl zeigt darüber hinaus, wie professionell die Entwicklerinnen und Entwickler vorgegangen sind. Wünschenswert ist eine Testabdeckung von 100 %, denn das bedeutet, dass jede Zeile Code von Tests abgedeckt wird. In der Praxis jedoch hat man immer wieder Bereiche, die sich nicht so ohne weiteres testen lassen, so dass eine realistische Testabdeckung von 80–90 % angestrebt werden sollte.
- Tests stellen schließlich sicher, dass auch tatsächlich das bearbeitet wird, was man sich vorgenommen hat und was auch erwartet wird.
Fehler in einer Software wird es immer geben, solange die Software lebt, das heißt, solange mit ihr und an ihr gearbeitet wird. Damit aber die Zahl der Fehler so gering wie nur irgend möglich bleibt, gehören Softwaretests zum Qualitätsmanagement dazu, denn sie sind ein essentieller Teil der Qualitätssicherung.
Foto: NESA by Makers on Unsplash