Unit-Test

Programme bestehen aus vielen kleinen Bausteinen. Jeder Baustein bekommt etwas hineingereicht und gibt ein Ergebnis zurück, zum Beispiel den Preis inklusive Mehrwertsteuer. Ein Unit-Test ist ein zweites, sehr kleines Programm, das genau so einen Baustein ausprobiert. Es ruft ihn mit festgelegten Werten auf und vergleicht das Ergebnis mit dem, was herauskommen sollte. Stimmt beides überein, gilt der Test als bestanden. Weicht das Ergebnis ab, schlägt der Test fehl und meldet die Stelle. Das Wort „Unit“ ist Englisch für Einheit und meint hier eben diesen einzelnen Baustein.

Der Rauchmelder für Code

Software wird ständig verändert. Jemand baut eine neue Funktion ein oder räumt alten Code auf. Dabei geht regelmäßig etwas kaputt, das vorher funktioniert hat. Solche Fehler heißen Regressionen. Ohne Tests fällt eine Regression oft erst Wochen später auf, wenn sich ein Nutzer beschwert.

Unit-Tests drehen diese Reihenfolge um. Ein Projekt hat schnell mehrere tausend davon. Sie laufen automatisch bei jeder Änderung, oft in unter einer Minute. Der Entwickler sieht den Fehler also, während er noch weiß, was er gerade getan hat. Das ist der eigentliche Gewinn: Fehler früh zu finden ist um ein Vielfaches billiger, als sie später in einem laufenden Produkt zu reparieren.

Ein zweiter Effekt wird oft unterschätzt. Wer weiß, dass Tests ihn absichern, traut sich eher, unübersichtlichen Code umzubauen. Ohne dieses Netz bleibt vieles jahrelang unangetastet, weil niemand das Risiko tragen will.

Aufbau eines einzelnen Tests

Fast jeder Unit-Test hat drei Schritte. Zuerst wird die Ausgangslage hergestellt, etwa ein Warenkorb mit zwei Artikeln. Dann wird der zu prüfende Baustein aufgerufen. Zum Schluss folgt die Behauptung, im Fachjargon Assertion genannt: Das Ergebnis muss 23,80 Euro sein. Diese Behauptung schreibt der Mensch, nicht der Computer.

Wichtig ist die Abgrenzung nach oben. Ein Unit-Test prüft nur den einen Baustein, nicht das Zusammenspiel mit Datenbank oder Internet. Braucht der Baustein trotzdem einen Partner, ersetzt man ihn durch eine Attrappe, ein sogenanntes Mock. Diese Attrappe liefert eine feste Antwort, damit der Test schnell und immer gleich abläuft. Tests, die das echte Zusammenspiel prüfen, heißen dagegen Integrationstests.

Eine häufige Kennzahl ist die Testabdeckung. Sie sagt, welcher Anteil der Code-Zeilen beim Testen überhaupt durchlaufen wurde. Ein verbreiteter Irrtum ist, dass hohe Abdeckung fehlerfreie Software bedeutet. Sie zeigt nur, dass Code ausgeführt wurde, nicht dass jemand sinnvolle Behauptungen darüber aufgestellt hat.

Von der Pipeline bis zum KI-Assistenten

In fast jedem Software-Unternehmen laufen Unit-Tests automatisch auf einem Server, sobald jemand neuen Code einreicht. Dieser Ablauf heißt Continuous Integration. Schlägt ein Test fehl, wird die Änderung blockiert und darf nicht ins Produkt. Auf Plattformen wie GitHub sieht man das an grünen Haken und roten Kreuzen neben jedem Beitrag.

Auch in der KI-Welt spielen Unit-Tests eine wachsende Rolle. Programmierassistenten wie GitHub Copilot oder Claude schreiben Tests inzwischen auf Zuruf mit. Umgekehrt dienen Tests als Prüfstein für die Modelle selbst: In Benchmarks wie SWE-bench muss eine KI echte Fehler in Open-Source-Projekten beheben. Als bestanden gilt eine Lösung nur, wenn danach alle Tests durchlaufen. Der Test ist hier also der neutrale Schiedsrichter.

Für dich selbst wird das relevant, sobald du ein Projekt schreibst, das länger als ein Wochenende lebt. Schon zehn gute Tests ersparen viel Sucherei, wenn du nach drei Monaten wieder hineinschaust.