Viele Einsteiger schreiben einen Unit-Test – und der Test baut heimlich eine Datenbankverbindung auf. Der Test wird langsam, bricht ohne Netz und misst plötzlich viel mehr als die eine Funktion.

Viele denken, ein Test müsse „echt“ sein, also mit echter Datenbank und echten APIs, sonst sei er wertlos. Das klingt plausibel, weil Software am Ende ja wirklich laufen muss.

Tatsächlich prüft ein Unit-Test nur eine Einheit isoliert – meist eine einzelne Funktion oder Methode einer Klasse. Abhängigkeiten wie Datenbanken oder APIs werden dafür durch Test-Doubles ersetzt, also Nachahmungen, die festgelegte Werte liefern. Solche Tests laufen in Millisekunden und ganz ohne Netz. Das Zusammenspiel mit echten Nachbarn prüfen stattdessen Integrationstests, etwa gegen eine echte PostgreSQL-Instanz.

Der Irrtum entsteht, weil „Test“ sich erst einmal gleich anhört, egal welche Schicht er prüft. Die Testpyramide rät deshalb ausdrücklich: viele schnelle Unit-Tests, weniger Integrationstests und wenige End-to-End-Tests, also Tests über die gesamte Anwendung hinweg.

Ein Beispiel: Eine Funktion berechnet den Bruttopreis aus Nettopreis und Steuersatz. Ihr Unit-Test ruft sie mit konkreten Werten auf und vergleicht das Ergebnis mit dem erwarteten Wert, ganz ohne Datenbank. In Node.js reicht dafür seit Version 20 der eingebaute Test-Runner node:test.

„Woran man es erkennt:“ Läuft der Test offline in Millisekunden, prüft er eine Einheit. Berührt er Datenbank oder Netzwerk, ist er ein Integrationstest – und gegen eine gemockte Datenbank findet er keine SQL-Fehler, denn dafür gehört mindestens ein Test gegen die echte Datenbank-Engine dazu.

Unit heißt nicht „kleiner Test von irgendetwas“, sondern isolierte Prüfung einer Einheit mit Test-Doubles für alle Abhängigkeiten.

📌 Einheit isoliert · Test-Doubles · Testpyramide

📚 Webentwicklung von Grund auf · Tag 6 von 30
#testing #NodeJS #typescript #webdev