Automatisierte Tests: Warum ungetesteter Code Schulden ist

Theoretisch ist sich fast jedes Team einig, dass automatisierte Tests wichtig sind. Und in der Praxis findet fast jedes Team einen Vorwand, sie außen vor zu lassen. „Wir haben jetzt keine Zeit.“ „Das Projekt ist einfach.“ „Wir testen manuell.“ Es sind Sätze, die mit beeindruckender Regelmäßigkeit dem Moment vorausgehen, in dem alles zu zerbrechen beginnt.

Automatisiertes Testen gehört zu den Themen, bei denen der Abstand zwischen Sprache und Praxis enorm ist. Und diese Entfernung ist mit Kosten verbunden, die nicht auf einmal, sondern in steigenden Raten über die Lebensdauer eines Produkts gezahlt werden.

In diesem Text geht es darum, warum Tests nicht mehr optional sind und was sich wirklich ändert, wenn ein Team sie ernst nimmt. Es ist kein Tutorial. Es ist ein Argument, das Argument von jemandem, der auf beiden Seiten gesehen hat, was mit und ohne Tests passiert.

Was sind automatisierte Tests eigentlich?

Automatisierte Tests sind Programme, die automatisch prüfen, ob Ihre Software das tut, was sie tun soll. Anstatt dass eine Person auf jede Änderung klickt und sie manuell überprüft, führt eine Testsuite diese Prüfung in Sekundenschnelle und so oft wie nötig durch.

Aber das Testen auf „Überprüfen, ob es funktioniert“ zu reduzieren, geht am Sinn vorbei. Automatisierte Tests sind in erster Linie ein Sicherheitsnetz. Sie erfassen Wissen darüber, wie sich das System verhalten sollte, und warnen, wenn eine Änderung dieses Verhalten unterbricht.

Dieses Netzwerk verändert die Beziehung des Teams zum Code selbst völlig. Ohne sie ist jede Veränderung ein Glücksspiel. Damit ist jede Veränderung eine überprüfbare Hypothese.

Warum dies nicht verhandelbar wurde

Software wächst und verändert sich ständig. Funktionen werden hinzugefügt, Fehler behoben, Code wird neu organisiert. Jede dieser Änderungen birgt das Risiko, dass etwas kaputt geht, was zuvor funktioniert hat.

In einem kleinen System kann man alles von Hand testen. In einem realen System, das von Monat zu Monat wächst, ist dies unmöglich. Niemand kann sich bei jeder Änderung durch alle Abläufe klicken. Das Ergebnis des Versuchens sind Müdigkeit, Langsamkeit und Fehler, die trotzdem verschwinden.

Automatisierte Tests sind die Antwort auf dieses Skalenproblem. Sie ermöglichen das Wachstum von Software, ohne dass die Verifizierung zu einem menschlichen Engpass wird. Aus diesem Grund sind sie keine Weiterentwicklung reifer Teams mehr, sondern eine Grundvoraussetzung für den Aufbau von etwas Dauerhaftem.

Die These: Beim Testen geht es um Mut, nicht um Fehler

Hier ist meine Position, die Sie vielleicht überraschen wird. Der größte Wert automatisierter Tests besteht darin, keine Fehler zu finden. Es macht Mut, den Code zu ändern.

Denken Sie an das Team ohne Tests. Jede Veränderung in einem sensiblen Teil des Systems geht mit Angst einher. „Wird dadurch noch etwas kaputt gehen?“ Diese Angst lähmt. Es führt dazu, dass das Team Verbesserungen vermeidet, schlechten Code so belässt, wie er ist, und aus reiner Angst nicht ändert, was funktioniert. Das Produkt verrottet aus berechtigter Feigheit.

Denken Sie jetzt an das Team mit guten Tests. Die gleiche Veränderung geht mit Zuversicht einher. Wenn etwas kaputt geht, wissen die Tests sofort Bescheid. Das Team kann ohne Angst umgestalten, verbessern und weiterentwickeln. Diese Freiheit ist das wahre Geschenk des Testens. Sie schützen nicht nur das Bestehende, sondern geben dem Team auch die Möglichkeit, das zu gestalten, was als nächstes kommt.

Die Arten von Tests und wann sie jeweils verwendet werden

Nicht jeder Test ist gleich und das Verständnis der Unterschiede vermeidet verschwendeten Aufwand.

Unit-Tests prüfen kleine, isolierte Codeteile. Sie sind schnell, günstig und sollten die Basis sein. Sie erkennen spezifische Fehler und geben nahezu augenblicklich Feedback.

Integrationstests prüfen, ob verschiedene Teile gut zusammenarbeiten. Sie sind langsamer, aber sie erkennen Probleme, die die Einheiten der Einheit nicht sehen, die Fehler, die in den Knotenpunkten leben.

End-to-End-Tests simulieren die reale Nutzung von Anfang bis Ende. Sie sind am langsamsten und anfälligsten, kommen aber der Benutzererfahrung am nächsten. Sie sollten in den kritischsten Abläufen sparsam eingesetzt werden.

Die Weisheit liegt in der Balance: viele schnelle Tests unten, wenige langsame Tests oben. Die Umkehrung dieses Verhältnisses ist ein klassischer Fehler, der zu langsamen und instabilen Suiten führt, die das Team zu ignorieren lernt.

Ein anwendbares Beispiel

Stellen Sie sich ein System vor, das Sozialleistungen für ein öffentliches Programm berechnet. Die Regeln sind komplex und ändern sich je nach Gesetzgebung. Ein Rechenfehler könnte dazu führen, dass ein Bürger mehr oder weniger den falschen Betrag erhält.

Ohne Tests ist jede Regeländerung ein großes Risiko. Niemand ist sicher, dass die Änderung einer Regel nicht zum Verstoß gegen eine andere Regel geführt hat. Das Team wird von der Angst als Geisel genommen, und Fehler erreichen letztendlich den Bürger.

Mit automatisierten Tests, die Berechnungsregeln abdecken, wird jede Änderung in Sekundenschnelle anhand Dutzender bekannter Szenarien überprüft. Wenn eine Änderung einen Fall zum Scheitern bringt, weiß das Team dies vor der Veröffentlichung. Die Zuverlässigkeit hängt nicht mehr vom Gedächtnis einer Person ab und wird nun vom System garantiert. Bei etwas, das das Leben der Menschen betrifft, ist dieser Unterschied nicht technischer Natur, sondern ethischer Natur.

Die Fallen, die den Aufwand zunichtemachen

Die erste Gefahr besteht darin, nach Zahlen und nicht nach Werten zu testen. Teams, die einen Abdeckungsprozentsatz als Ziel verfolgen, schreiben am Ende nutzlose Tests, um die Metrik aufzublähen. Eine hohe Berichterstattung über schlechte Tests ist eine falsche Sicherheit.

Die zweite ist die langsame und instabile Suite. Wenn Tests zu lange dauern oder zufällig scheitern, verliert das Team das Vertrauen in sie und beginnt, sie zu ignorieren. Ein ausgelassener Test schützt niemanden. Die Wartung der Suite selbst ist eine fortlaufende Arbeit.

Die dritte besteht darin, das Testen als separate Aufgabe zu behandeln, die später erledigt wird. Tests funktionieren am besten, wenn sie Teil der Entwicklung sind und nicht, wenn sie zu einem zusätzlichen Schritt werden, der immer bis zum Ende verbleibt und nie stattfindet.

Code ohne Prüfung ist schuldenakkumulierende Zinsen

Letztendlich besteht die Wahl nicht darin, zu testen oder nicht zu testen. Es geht darum, sofort oder später zu zahlen, mit Zinsen. Ungetesteter Code ist eine technische Schuld, die stillschweigend wächst, bis die Rechnung zum ungünstigsten Zeitpunkt eintrifft.

Teams, die in Tests investieren, sind nicht langsamer, sie sind mutiger. Sie bewegen sich mit dem Selbstvertrauen von jemandem mit einem Sicherheitsnetz darunter. Und dieses Vertrauen, multipliziert mit Monaten und Jahren der Entwicklung, ist es, was Produkte, die sich weiterentwickeln, von Produkten unterscheidet, die rosten.

Beim Testen geht es nicht darum, Ihrem Code zu misstrauen. Es geht darum, die Zukunft derjenigen zu respektieren, die sie aufrechterhalten werden, einschließlich Ihnen selbst.

Wenn Ihr Team bei der Bereitstellung von Software Angst davor hat, Bestehendes zu verändern, liegt das Problem möglicherweise nicht an mangelnden Talenten, sondern an mangelndem Netzwerk. Es lohnt sich, darüber zu reden. Ich habe weitere Blogartikel über Softwarequalität, Best Practices und Engineering, die sich damit befassen, wie man dieses Vertrauen aufbaut.