In der agilen Softwareentwicklung ist das automatisierte Testen unerlässlich. Ohne das kann keine kontinuierliche Produktivität gewährleistet werden, weil die Angst, Anpassungen an dem System durchzuführen, immer größer wird. Um die Qualität automatisierter Tests zu bewerten, kann man verschiedene Kriterien heranziehen. Das offensichtlichste Kriterium ist, dass der Test tatsächlich überprüft, ob sich das System Under Test (SUT) wie erwartet verhält. Um das sicherzustellen, wird beim Test Driven Development zuerst der Test geschrieben, der fehlschlagen muss, bis die Funktionalität implementiert ist. Dies garantiert zwar noch nicht, dass alle Fälle getestet werden, aber wenigstens, dass dieser Testfall den Entwickler nicht in falscher Sicherheit wiegen lässt.

Das zweite Kriterium, was uns Entwicklern direkt ins Auge springt, ist die Testausführungszeit, denn sie bestimmt, wie kurz die Feedbackzyklen in der Entwicklung sein können.

Keine Angst vor Testanpassungen

Zu Beginn unterschätzte Eigenschaften von Tests sind die Anfälligkeit und Zerbrechlichkeit (engl. brittle tests). Diese beschreiben, wie robust die Tests gegenüber gewollten Codeanpassungen oder Umgebungsparametern sind. Zerbrechliche Tests können eine Vielzahl von Gründen haben. Dazu gehören zum Beispiel unnötig genaue Testassertions, eine zu hohe Code-Kohäsion, aber auch ein schlechtes Code-Design, bei dem die Funktionen auf einen globalen Status vertrauen. Will man aber Integrationstests schreiben, die zum Beispiel zeigen, ob das Laden und Manipulieren von Datensätzen in der Postgres-Datenbank funktioniert, ist eine ganze Datenbank ein Teil des SUT. Für jeden Testfall eine eigene oder neue Datenbank hochzufahren wäre eine mögliche Lösung, würde aber die Testausführungszeit deutlich erhöhen und unnötig Ressourcen kosten.

Aufräumen im Setup?

Damit die Testergebnisse durch andere Tests nicht verfälscht werden, gibt es in den meisten Testing-Frameworks das Konzept von Test-Setups und Test-Teardowns. Das Setup dient dazu den globalen Zustand, der von den Tests benötigt wird, herzustellen. In dem Teardown können Aufräumarbeiten durchgeführt werden. Soweit ist die Erkenntnis vielleicht nicht überraschend. Wenn jeder Test im Setup die Datenbankverbindung öffnet und im Teardown die Datenbank bereinigt, funktioniert alles wie erwartet.

Was passiert jedoch, wenn ein Testfall sein Teardown nicht vollständig durchführt? Dann zerschießt es einem meist viele Tests und führt dazu, dass das eigentliche Problem durch Testfehlermeldungen verdeckt wird. Beispielsweise dann, wenn eine Filterfunktion getestet wird. Dabei werden Daten in die Datenbank geschrieben, die Filterfunktion wird aufgerufen und es wird überprüft, ob die zu dem Filter passenden Daten zurückgegeben werden. Befinden sich vor der Ausführung dieses Tests schon Daten in der Datenbank, die zu diesem Filter passen, werden diese auch zurückgegeben und der Test schlägt fehl. Deshalb hat es sich bewährt, bei den Setups der Testcases nicht nur die benötigten Ressourcen anzufragen, sondern auch einen Zustand in allen Abhängigkeiten herzustellen, der für die Testausführung von Nöten ist. Dazu kann auch gehören, eine leere Tabelle sicherzustellen.

Einfaches Debugging durch einen sinnvollen Teardown

Wozu genau ist der Teardown dann noch da? In diesem ist es möglich Ressourcen wieder freizugeben ohne Daten aufräumen zu müssen. Dies fühlt sich im ersten Moment zwar unsauber an, sorgt aber für ein einfacheres Debugging. Denn wenn nur einzelne Testcases ausgeführt werden, kann danach in aller Ruhe untersucht werden, in was für einem Zustand sie die anderen Abhängigkeiten zurückgelassen haben.

Zu guter Letzt sollten externe Ressourcen bei dem Teardown der ganzen Test-Suite aufgeräumt werden, damit auch alles seine Ordnung hat.

Habt Ihr Fragen zu automatisierten Tests? Meldet Euch!

Wenn es weitere Themen im Bezug auf automatisierte Tests gibt, die Euch beschäftigen, freue ich mich über den Kontakt mit Euch. Falls Ihr z.B. gemerkt habt, dass die intuitivste Herangehensweise vielleicht nicht die Beste ist. Oder habt ihr Lust Testing, Microservices, Go oder Kafka in einem Workshop näher kennenzulernen? Ich freue mich über Eure Mails an f.vosberg@tarent.de.