Warum Test-Driven Development?

Test Driven Development (TDD) ist eine Technik, die erfahrene Software Engineers einsetzen, um sicherzustellen, dass der Zustand einer Anwendung dem entspricht, was beabsichtigt ist. In traditionelleren Anwendungen und in der Geschichte des Software Engineerings insgesamt hat Testing seinen festen Platz in jedem erfolgreichen und professionell entwickelten Software-System gefunden. Trotzdem gibt es heute noch unzählige Unternehmen, die der Meinung sind, dass das Schreiben von Tests die Entwicklung verlangsamt, Kosten erhöht und generell Zeitverschwendung ist. Dieser Artikel soll zeigen, warum diese Aussage nicht weiter von der Wahrheit entfernt sein könnte.

Was bringt Software zum Absturz?

Perfekt geschriebene Software existiert nicht. (Höchstwahrscheinlich) nie. Der Begriff „Bug" wurde 1946 in Harvard geprägt. Damals verbreitete Grace Hopper die Geschichte einer Motte, die in einem frühen elektromechanischen Computer Probleme verursachte. Hopper arbeitete am Mark II/III-Computersystem in Harvard, als festgestellt wurde, dass eine Motte in einem Relais steckte und Fehler verursachte.

Nachdem die Motte entfernt wurde, notierte Hopper in seinen Aufzeichnungen: „First actual case of bug being found". Der Begriff „Bug" war geboren und wird seitdem für unerwartetes Verhalten in einem Computersystem verwendet. Wie hoch ist die Wahrscheinlichkeit, dass ein System Bugs enthält? 100 von 100 Projekten. Wie hoch ist sie, wenn ich die besten Entwickler der Welt einstelle? 100 von 100 Projekten. Bessere Entwickler lösen das Problem also nicht – sie reduzieren die Anzahl der Bugs, aber nicht ihre grundsätzliche Existenz. Genau deshalb werden Tests geschrieben: weil es keine fehlerfreie Software gibt.

Grace Hoppers Bug (1946)

TDD: Kosten senken, Qualität steigern

Bei Test-Driven Development (TDD) schreiben Engineers die Tests, bevor sie die eigentliche Logik implementieren. Ohne zu technisch zu werden, führt das zu Folgendem: Wenn es richtig gemacht wird, stellt es sicher, dass kein ungetesteter Code ins Repository gelangt – weil du den Test bereits im Voraus geschrieben hast. Löst das das Bug-Problem von oben? Leider nein. Aber es ist eine der besten Techniken, die wir haben, um robuste und widerstandsfähige Software zu bauen.

"Annahmen früh validieren, um teure Fehler später zu vermeiden."

Was ist jetzt der Unterschied bei Web3? Security hat in der Web3-Entwicklung oberste Priorität. Smart Contracts verwalten oft erhebliche Mengen an Kryptowährungen und anderen digitalen Assets. Jede Schwachstelle in diesen Contracts kann zu massiven finanziellen Verlusten führen. TDD spielt eine entscheidende Rolle bei der Sicherheit, indem es kontinuierliches Testing und die frühzeitige Erkennung potenzieller Probleme fördert.

Indem Sicherheitslücken früh im Entwicklungszyklus gefunden werden, schützt TDD vor Exploits und Angriffen, die die Integrität einer dezentralen Anwendung gefährden könnten. Testing gibt Engineers die Möglichkeit, die Codebasis anzupassen und sofortiges Feedback zu erhalten. Wenn Tests sauber geschrieben sind, wird jede Code-Änderung, die zu einem Bug führen könnte, von einem Test abgefangen und gemeldet.

Wichtig: All das oben Genannte ist auch mit einfachem Testing möglich. Also Tests schreiben, wann immer man gerade denkt: „jetzt wäre ein guter Zeitpunkt." Viele Entwickler folgen dem Motto: „Ich schreibe jetzt den Code und wenn ich Zeit habe, schreibe ich den Test." Das ist bis zu einem gewissen Grad OK. Besser als gar keine Tests zu schreiben! Aber es erreicht niemals das Resilienz-Level von TDD, weil es den Kern der Idee völlig verfehlt. Ich wiederhole mich gerne: „Kein ungetesteter Code kommt in die Produktion." Das ist, was reines TDD garantiert.

Kein Testing wird sich irgendwann rächen

Der stille Killer: Technical Debt

Jetzt bin ich dir noch eine Erklärung schuldig, warum das Weglassen von Tests die Entwicklungs- und Wartungskosten in die Höhe treibt. Das Stichwort lautet Technical Debt. Software enthält immer Bugs. Je länger sie existiert und je größer sie wird, desto mehr Bugs produziert sie. Das ist keine Erfindung von mir – das ist eine bekannte Tatsache. Wenn es keine Gegenmaßnahme gibt, um diese Bugs zu finden und zu eliminieren, leben sie weiter und beeinflussen regelmäßig neuen Code, der zur Codebasis hinzugefügt wird. Je mehr Features hinzukommen, desto größer wird das Problem. Und irgendwann bricht der Turm zusammen – und du stehst vor einer nicht mehr kontrollierbaren Codebasis.

Das Ergebnis: ein vollständiger oder teilweiser Neuaufbau deines Projekts.

Stell dir eine kleine Stadt vor, die schnell eine Brücke baut, um zwei Ufer zu verbinden. Die Engineers überspringen in ihrer Eile einige Sicherheitsprüfungen und verwenden minderwertiges Material. Zunächst funktioniert die Brücke einwandfrei, alle sind zufrieden. Im Laufe der Zeit fahren immer mehr Autos darüber. Kleine Risse entstehen, werden aber ignoriert, weil die Brücke ja noch steht. Jedes neue Fahrzeug erhöht die Belastung, die Risse werden größer. Eines Tages fährt ein schwer beladener LKW darüber – und die Brücke bricht zusammen.

Genau das passiert mit Technical Debt in Software. Frühe Abkürzungen und ungetesteter Code schaffen versteckte Probleme. Mit jedem neuen Feature wachsen diese Probleme, bis das System fragil wird. Am Ende kann eine scheinbar kleine Änderung einen katastrophalen Ausfall auslösen – genau wie der überladene LKW auf der Brücke. Ohne Tests, die Probleme früh abfangen, wird die Software nicht mehr tragbar – mit explodierenden Kosten und schließlich dem Kollaps als Folge.

Tipp #1: Wenn du Entwickler einstellst, teste ihre Testing-Kompetenz mit einfachen Fragen:

→ Welche Erfahrung hast du mit dem Schreiben von Tests?
→ Welche Art von Tests bevorzugst du für dieses Projekt, und warum?
→ Müssen wir wirklich Tests schreiben?

Tipp #2: Wem Testing egal ist, dem ist dein Produkt egal.

Klingt hart, ist aber die Wahrheit.

Dein Projekt wird ohne Tests irgendwann sterben – da führt kein Weg dran vorbei.