Wie Entwickler ihren Code testen sollten

Die vier häufigsten Fehler beim Testen

Jan Weddehage

© Shutterstock.com / peachyspirit

Mit dem Testen ist es ein Kreuz. Es ist mühsam, zeitaufwendig und macht nicht halb so viel Spaß wie das kreative Coden selbst. Drumherum kommen Entwickler aber nun mal nicht. Wir haben die vier häufigsten Fehler beim Testen zusammengestellt und wie man diese vermeidet.

Das Testen von Code gehört nicht zu den Lieblingsaufgaben von Entwicklern und wird gerne gemieden oder an Dritte abgegeben. Es gibt aber Ausnahmen wie Matt Lacey, der ins Testen mehr Zeit als ins Coding investiert. Lacey ist der Meinung, dass die eigene Produktivität durch ein kontinuierliche Code-Tests gesteigert werden kann. Das gilt jedoch nur, wenn es richtig durchgeführt wird. Die häufigsten Fehler, über die Entwickler stolpern, hat er in seinem Artikel „11 Things You’re Doing Wrong When Testing Code“ zusammengestellt. Wir werfen einen Blick auf die vier schwerwiegendsten.

1. Nichts spricht gegen Testen

Der größte Fehler, den die meisten Entwickler begehen, liegt darin, gar nicht erst mit dem Testen zu beginnen. Allerdings gibt es dafür keine Entschuldigung: Weder mangelnde Motivation noch die Ausrede, dass andere ihre Codeversatzstücke ebenfalls nicht testen, sind keine guten Gründen. Und ebenfalls rechtfertigt der Verweis, dass ein Projekt bereits angelaufen ist, den Verzicht auf die Überprüfung nicht. Vielmehr sollte gerade in solchen Situationen damit begonnen werden, Pläne für das Testing aufzustellen, selbst wenn die Integration im Nachhinein Veränderungen an der Architektur notwendig machen sollte. Generell gilt: Wenn Testing von Anfang an in ein Projekt implementiert wird, dann kann man sich im weiteren Verlauf viel Geld und Aufwand sparen.

2. Es geht nicht um fehlerhafte Tests

Weil die testgetriebene Entwicklung sich einer großer Popularität erfreut, findet das Red-Green-Refactor in der Softwareentwicklung immer öfter Verwendung. Während Rot das Scheitern eines Tests signalisiert, verweist Grün auf einen positiven Durchlauf. Viele Entwickler machen nun allerdings den Fehler, die Idee hinter dem Test Driven Developments falsch auszulegen. Es geht in erster Linie nicht darum, kontinuierlich fehlerhafte Tests zu schreiben, sie zu beheben und das Ganze wieder von vorne zu beginnen. Das Erstellen von Tests vor der eigentlichen Programmierarbeit ist vielmehr dazu gedacht, im Vorhinein zu bestimmen, wie sich das System korrekt verhalten soll.

Fehlerhafte Tests sind somit nicht der Ausgangspunkt, sondern das Ergebnis testgetriebener Entwicklungen. Dabei ist es wichtig, die Tests mit Namen zu versehen, die eindeutige Rückschlüsse auf das Verhalten, das vom System erwartet wird, geben. Auf welche Konventionen bei der Benennung zurückgegriffen wird, ist jedem selbst überlassen. Entscheidend ist, dass die Kennzeichnung eine gewisse Kohärenz besitzt und klar auf den zu testenden Sachverhalt hinweist. Auf diese Weise können Tests wichtige Informationen liefern.

Lesen Sie auch: Interview mit Stephan Kaps: “Wer Software kontinuierlich ausliefern will, muss auch kontinuierlich testen”

3. Zu viel, zu einseitig, zu kurz

Bei der richtigen Benennung können Entwicklern ebenfalls Fehler unterlaufen. Eine der häufigsten Ursachen des Scheiterns von Tests liegt darin, dass zu viel auf einmal getestet werden soll. Hierfür sind lange und komplizierte Kennzeichnungen gute Indikatoren. Ein guter Test zeichnet sich dadurch aus, dass jeweils nur eine Sache überprüft wird. Wenn ein Test scheitert, sollte die Ursache im Code eindeutig gekennzeichnet werden. Muss erst im Code nachgeschaut werden, um den Fehler zu lokalisieren, läuft etwas schief. Das bedeutet im Umkehrschluss aber nicht, dass mehrere Sachen niemals gleichzeitig getestet werden dürfen. Es sollte allerdings darauf geachtet werden, dass sie in einer engen Korrelation zueinander stehen.

Doch oft wird nicht nur zu viel, sondern auch zu einseitig getestet. Weitere Optionen werden häufig ausgeblendet, wenn man sich zu stark auf ein Testverfahren festlegt. Es ist nicht möglich, alle Teile eines Systems mit nur einem Verfahren zu überprüfen. So sind etwa Unit-Tests erforderlich, um sicherzustellen, dass die individuellen Komponenten richtig funktionieren. Und Integrationstests bestätigen, dass die verschiedenen Komponenten zusammen funktionieren. Ferner werden automatisierte UI-Tests benötig, um zu verifizieren, dass die Software so funktioniert, wie es vorgesehen war.

Hinzu kommt, dass Tests ihr volles Potenzial erst im Laufe der Zeit entwickeln. Sie sollen nicht nur feststellen, dass etwas richtig programmiert wurde. Sie müssen vielmehr das einwandfreie Funktionieren auch nach weiteren Veränderungen an der Codebasis garantieren können. Um also in der Lage zu sein, Probleme so früh wie möglich zu erkennen und zu beheben, müssen Tests ständig wiederholt werden. Darin liegt der Vorteil von schnellen und automatisierten Tests.

Vor allem im Rahmen eines Continuous-Integration-Systems ist die Automatisierung von Tests ein guter Anfang. Allerdings darf nicht übersehen werden, dass jedem, der an einem Projekt beteiligt ist, die Durchführung von Tests ermöglicht werden muss. Häufig wird der Fehler gemacht, das Testing durch spezielle Setups, Freigaben oder Konfigurationen unnötig zu erschweren und so vom Coding zu trennen. Entwickler müssen jedoch in der Lage seinen, vor, während und nach ihren Programmierarbeiten eigenständig Tests durchführen zu können. Anders kann die Fehlerfreiheit von Software nicht garantiert werden.

Lesen Sie auch: Warum Entwicklern das Testen so schwer fällt – und wie man besser werden kann

4. Die Code Coverage ist nicht entscheidend

Die Code Coverage ist zwar eine gute Sache, hat aber im Code Testing lediglich einen begrenzten Wert. Denn wie viel Code während eines Tests ausgeführt wird, lässt nur wenige Rückschlüsse auf die Qualität des Testverfahrens zu. Hilfreiche Aussagen liefert höchstens die Codeabdeckung. Ist die Abdeckung hoch, kann das bedeuten, dass bereits genügend Tests vorliegen und ein weiterer keine zusätzlichen Erkenntnisse liefert. Ist die Abdeckung hingegen niedrig, kann das ein Anzeichen dafür sein, dass nicht ausreichend Tests vorhanden sind.

Aber auch hierbei ist Vorsicht geboten, da eine hohe Codeabdeckung ebenfalls mit Tests erzielt werden kann, die nichts überprüfen. Zielen die Tests nur darauf ab, die Code Coverage zu steigern, sind sie in den meisten Fällen nutzlos. Aber wie kann dann bestimmt werden, wann ein Codebaustein getestet werden muss oder nicht?

Die Frage lässt sich folgendermaßen beantworten: Wenn der Code eine nicht-triviale Komplexität aufweist, ist ein Testing erforderlich. Weist er eine solche nicht auf, ist keine Überprüfung notwendig. Codeversatzstücke besitzen eine nicht-trivialen Komplexität, wenn deren Funktionen während des Programmierens oder im Review-Verfahren nicht auf den ersten Blick eindeutig zugeordnet werden können. Werden also Fehler in existierenden Codebausteinen festgestellt, ist das meistens darauf zurückzuführen, dass die Komplexität nicht hinreichend überprüft wurde.

Verwandte Themen:

Geschrieben von
Jan Weddehage
Jan Weddehage
Jan Weddehage studiert an der Goethe Universität Frankfurt am Main und arbeitet seit März 2015 als Werkstudent bei Software & Support. Kontakt: jan[at]janweddehage.de
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: