JavaScript testen

JavaScript — Testen

0:00 Im letzten Modul haben wir Vorhersagen getroffen und sie dann von Hand geprüft. Jetzt lassen wir das den Computer machen — und zwar jedes Mal, automatisch. Genau das ist ein Test: eine aufgeschriebene Erwartung, die auf Knopfdruck geprüft wird. Und damit ändert sich die Bedeutung eines fehlschlagenden Tests grundlegend.

0:19 Er ist keine Niederlage, sondern eine Information: Hier stimmt etwas nicht mit dem überein, was Sie erwartet haben. Diese Haltung ist wichtiger als jedes Werkzeug — und sie ist der rote Faden dieses Moduls.

Verhalten absichern

0:32 Vier Kapitel. Zuerst die Begriffe, denn beim Testen kursieren einige, die durcheinandergehen — besonders einer, der gern als Ziel missverstanden wird. Dann zwei Werkzeuge in der Praxis: Jest, das Ihnen in vielen Bestandsprojekten begegnet, und Vitest, das in modernen Projekten üblich ist. Sie werden sehen, wie ähnlich sich beide sind.

0:51 Und zum Schluss der eigentlich spannendste Teil: Wie man mit Tests Fehler findet — durchgespielt an einem echten Fehlerbericht, mit einer Ursache, die Sie wiedererkennen werden.

Begriffe des Unit-Testens

1:03 Beginnen wir mit dem Vokabular. Vier Begriffe, und einer davon wird in Projekten regelmäßig zum Ziel erklärt, obwohl er nur eine Kennzahl ist. Wir ordnen ihn gleich am Anfang richtig ein, damit er später keinen Schaden anrichtet. Ein Unit-Test prüft eine kleine Verhaltenseinheit — in JavaScript meist eine einzelne Funktion. Das Wort „klein" ist dabei entscheidend.

1:25 Der Mechanismus ist erfreulich schlicht: mit bekannten Eingaben aufrufen, das tatsächliche Ergebnis mit dem erwarteten vergleichen. Mehr passiert nicht. Und genau hier zahlt sich aus, was wir im Funktionsmodul gebaut haben. Eine Funktion, die einen Wert zurückgibt, lässt sich prüfen. Eine Funktion, die stattdessen direkt etwas ausgibt, kaum. Testbarkeit ist also keine Eigenschaft, die man nachträglich hinzufügt — sie entsteht beim Entwurf.

1:54 Vier Begriffe, drei davon unproblematisch. Der Testfall ist ein konkretes Szenario mit erwartetem Ergebnis. Die Testsuite bündelt zusammengehörende Fälle. Die Zusicherung ist die eigentliche Prüfung. Und dann die Abdeckung — der Anteil des Codes, den die Tests ausgeführt haben. Der Fußtext sagt das Wesentliche dazu: Hohe Abdeckung mit schwachen Zusicherungen beweist nichts.

2:17 Sie können jede Zeile Ihres Programms ausführen und dabei nichts Sinnvolles prüfen. Die Zahl sieht dann hervorragend aus. Abdeckung ist ein nützlicher Hinweis auf ungeprüfte Bereiche — sie ist kein Qualitätsziel für sich. Vier Nutzen, und der zweite ist der, weswegen Profis nicht mehr ohne arbeiten wollen. Der erste ist der offensichtliche: Erwartetes Verhalten wird überprüfbar statt behauptet.

2:42 Der zweite ist der wirtschaftliche — Sie können umbauen, ohne bei jeder Änderung alles von Hand durchzuklicken. Genau das macht Refactoring erst bezahlbar. Der dritte ist die Diagnosequalität: Ein Fehlschlag sagt Ihnen, welche Erwartung verletzt wurde, nicht nur dass etwas kaputt ist. Und der vierte ist ein angenehmer Nebeneffekt: Tests dokumentieren, wofür eine Funktion gedacht ist — und zwar in einer Form, die nicht veralten kann, weil sie sonst rot wird.

3:10 Drei Werkzeuge, drei Situationen. Jest ist seit Jahren verbreitet und begegnet Ihnen in praktisch jedem gewachsenen Projekt. Vitest ist die moderne Wahl, besonders im Umfeld des Build-Werkzeugs Vite. Und die dritte Zeile verdient Beachtung, weil sie oft übersehen wird: Node bringt inzwischen einen eigenen Testläufer mit, ganz ohne zusätzliche Abhängigkeit.

3:31 Für ein kleines Werkzeug ist das oft völlig ausreichend. Der Fußtext nimmt Ihnen den Entscheidungsdruck: Für den Einstieg spielt die Wahl kaum eine Rolle. Die Denkweise ist bei allen dieselbe, und die ist das eigentlich Übertragbare. Benennen Sie zu einer Funktion mit Schwellenwerten mindestens vier Testfälle — und zwar bevor Sie einen Test schreiben. Beide Grenzwerte müssen dabei sein.

3:54 Das ist dieselbe Denkbewegung wie beim Pseudocode im letzten Modul: erst die Szenarien klären, dann die Umsetzung. Der Hinweis nennt die ergiebigste Stelle: Grenzwerte, genau am Schwellenwert und knapp darunter. Dort wohnen die Fehler um eins, die wir im letzten Modul gesehen haben. Ein Test bei Wert drei und einer bei Wert zwanzig prüft weniger als zwei Tests direkt an der Grenze.

4:17 Nur den Normalfall zu prüfen, ist der häufigste Anfängerfehler — und der Test fühlt sich dann trügerisch gut an, weil er ja grün ist. Der zweite Punkt ist die Abdeckungsfalle aus der Tabelle: Wer die Zahl zum Ziel macht, schreibt Tests, die viel ausführen und wenig prüfen. Der dritte ist eine Haltungsfrage, die überraschend viel ausmacht: Ein Fehlschlag ist ein Befund, keine Störung. Wer ihn als Ärgernis empfindet, schreibt bald weniger Tests.

4:43 Und der vierte ist praktisch: Zu große Einheiten zu testen, bedeutet, dass ein roter Test Ihnen nicht mehr sagt, wo das Problem liegt.

Erste Tests mit Jest

4:51 Jetzt praktisch, mit dem Werkzeug, das Ihnen im Bestand am häufigsten begegnet. Wir richten es ein, schreiben Tests und lassen sie laufen. Und am Ende bauen wir absichtlich einen Fehler ein — denn das ist der Moment, in dem man versteht, was ein Test eigentlich leistet. Drei Dinge müssen Sie über Jest wissen. Erstens: Es findet Testdateien selbst, über Namenskonventionen — Sie müssen also nichts registrieren, sondern nur richtig benennen.

5:18 Zweitens stellt es zwei Bausteine bereit: eine Funktion für den einzelnen Testfall und eine für die Zusicherung. Und drittens läuft es über ein Skript in der Projektdatei. Diese drei Punkte gelten sinngemäß für alle Test-Frameworks, die Sie treffen werden. Wenn Sie sie einmal verstanden haben, ist das nächste Werkzeug eine Frage von zwanzig Minuten, nicht von zwei Tagen.

5:40 Fünf Schritte, und der rote Faden lautet: Projekt aufsetzen, Werkzeug holen, Einstiegspunkt definieren, Datei anlegen. Interessant ist Schritt drei, genauer der Zusatz „Entwicklungsabhängigkeit". Der Fußtext erklärt, was das heißt: Ein Testwerkzeug wird nur beim Entwickeln gebraucht, nicht im laufenden Betrieb. Diese Unterscheidung hat praktische Folgen — sie hält die ausgelieferte Anwendung kleiner und die Angriffsfläche geringer.

6:07 Schritt vier ist der, den man am ehesten vergisst: das Skript in der Projektdatei. Ohne es läuft der Testbefehl ins Leere. Und Schritt fünf ist die Namenskonvention, an die sich das Werkzeug hält. Zwei Tests, und beide folgen demselben Dreischritt: Funktion aufrufen, Ergebnis einpacken, mit dem Erwarteten vergleichen. Das liest sich fast wie ein englischer Satz — erwarte, dass das Ergebnis dies ist. Achten Sie auf die Beschreibungen in Anführungszeichen.

6:35 Sie sind kein Beiwerk, sondern das, was Ihnen bei einem Fehlschlag entgegenspringt. Der Fußtext sagt es deutlich: Die Beschreibung soll den Fall benennen, nicht nummerieren. „Test drei schlägt fehl" hilft niemandem. „Genau fünf Jahre ergibt etabliert" sagt Ihnen sofort, worum es geht — und oft schon, wo Sie suchen müssen.

6:55 Diese Aufgabe ist der wichtigste Durchgang des Kapitels, und sie klingt paradox: Bauen Sie absichtlich einen Fehler ein. Ändern Sie einen Vergleich — ein einfaches Größerzeichen statt größer-gleich ist der klassische Kandidat —, schreiben Sie einen Test, der fehlschlägt, und nehmen Sie die Änderung dann zurück. Alles wird wieder grün. Damit haben Sie den Rot-Grün-Zyklus einmal vollständig erlebt. Und Sie haben etwas Wichtigeres gesehen: dass Ihr Test wirklich greift.

7:23 Ein Test, der nie rot war, ist ein Test, von dem Sie nicht wissen, ob er etwas prüft. Testdateien falsch zu benennen, führt zu der frustrierendsten aller Meldungen: Es wurden keine Tests gefunden. Der Code ist in Ordnung, das Werkzeug schaut nur woanders hin. Das vergessene Skript in der Projektdatei erzeugt einen ähnlichen Effekt — der Befehl läuft ins Leere.

7:44 Der dritte Punkt ist die Beschreibungsfrage aus der letzten Folie, und sie zahlt sich erst ein halbes Jahr später aus, wenn ein Test rot wird, den Sie längst vergessen haben. Und der vierte ist der Klassiker jeder Fehlerbehebung: nach dem Beheben nicht erneut laufen lassen. Erstaunlich oft war die Korrektur nicht die richtige.

Erste Tests mit Vitest

8:03 Jetzt das moderne Gegenstück — und Sie werden überrascht sein, wie wenig sich ändert. Ein Testfall am Ende dieses Kapitels leitet direkt zum nächsten über, weil er genau den Fehler abdeckt, der uns seit Modul drei begleitet. Die Schreibweise ist nahezu identisch, mit einer Ergänzung: Es gibt eine Funktion zum Gruppieren zusammengehörender Fälle.

8:23 Damit entsteht Struktur in einer Testdatei — alle Tests zu einer Funktion stehen sichtbar zusammen. Der zweite Unterschied ist technischer Natur: Die Bausteine werden ausdrücklich importiert, statt global zur Verfügung zu stehen. Das ist sauberer und passt zur Modulwelt, die wir im übernächsten Modul behandeln. Ansonsten gilt: Wer Tests in dem einen Werkzeug schreiben kann, kann es auch im anderen.

8:47 Die Denkweise überträgt sich vollständig. Sie sehen die Gruppierung in Aktion: ein Rahmen mit dem Namen der Funktion, darin die einzelnen Fälle. Lesen Sie die Beschreibungen zusammen mit dem Rahmen, dann ergeben sie einen Satz — die Funktion lehnt eine leere Zeichenkette ab, die Funktion akzeptiert die Null als gültig. So entsteht eine Spezifikation, die man lesen kann. Und der Fußtext markiert den wichtigsten Fall: Die Null ist unwahr im technischen Sinn, aber fachlich gültig.

9:15 Genau dieser Test würde den Fehler aufdecken, den der falsche Fallback-Operator erzeugt. Wir sehen ihn im nächsten Kapitel in freier Wildbahn. Die Botschaft dieser Tabelle ist Entwarnung. Die Schreibweise ist nahezu identisch — die drei Bausteine heißen gleich und verhalten sich gleich. Unterschiede gibt es beim Modulsystem, worauf wir im Modul über Module zurückkommen, und bei der Rückmeldung: Vitest beobachtet Änderungen und läuft von selbst erneut, was den Zyklus angenehm beschleunigt.

9:44 Der letzte Punkt ist die Einordnung, die Sie im Berufsleben brauchen: Jest im Bestand, Vitest in modernen Projekten. Und der Fußtext fasst es zusammen — für den Einstieg ist das keine Grundsatzentscheidung. Beide prüfen Code gegen Erwartungen. Decken Sie in einer Gruppe vier Fälle ab: leere Zeichenkette, null, undefined und die Null — und die Null muss dabei als gültig gelten.

10:06 Diese vier Fälle sind nicht zufällig gewählt. Sie sind exakt die Werte, bei denen die Sprache Ihnen Fallen stellt, und drei davon sehen sich zum Verwechseln ähnlich. Der Hinweis nennt den Zweck: Ein Test, der die Null als gültig fordert, deckt genau den Fehler auf, den der Oder-Operator als Fallback erzeugt. Sie schreiben hier also einen Test gegen einen Fehler, den Sie inzwischen kennen — und das ist die beste Art zu lernen.

10:31 Die ersten beiden Punkte sind Modulthemen, die uns in Modul vierzehn begegnen werden: die fehlende Typangabe in der Projektdatei und die weggelassene Dateiendung im Import. Beide führen zu Fehlermeldungen, die zunächst nichts mit Tests zu tun zu haben scheinen. Der dritte Punkt ist eine Frage der Diagnose: Alle Fälle in einen einzigen Test zu packen, spart Tipparbeit und kostet Aussagekraft — schlägt er fehl, wissen Sie nicht, welcher Fall es war.

10:56 Und der vierte ist unser Dauerbrenner: den Fall Null auszulassen, weil er wie ein leerer Wert aussieht. Genau deshalb muss er hinein.

Mit Tests Fehler finden

11:04 Zum Abschluss der Teil, für den sich das Ganze wirklich lohnt. Ein Fehler wird gemeldet — was jetzt? Die Reihenfolge der Schritte ist dabei entscheidend, und sie widerspricht dem, was man instinktiv tut. Der erste Satz enthält eine wichtige Unterscheidung: Ein Fehlerbericht beschreibt ein Symptom, nicht die Ursache. Jemand sagt Ihnen, was er gesehen hat — warum es passiert, weiß er nicht.

11:28 Der Weg führt dann über vier Stationen: reproduzieren, einen fehlschlagenden Test schreiben, korrigieren, erneut laufen lassen. Und der letzte Halbsatz ist der eigentliche Gewinn: Der Test bleibt danach als Sicherung bestehen. Sie haben nicht nur einen Fehler behoben, Sie haben dafür gesorgt, dass genau dieser Fehler nie wieder unbemerkt zurückkommt.

11:48 Das nennt man Regressionsschutz, und er summiert sich über die Jahre. Fünf Schritte, und Schritt zwei ist der, den man am liebsten überspringt: erst der Test, dann die Korrektur. Und der Fußtext erklärt, warum das nicht verhandelbar ist — schlägt der Test vor der Korrektur nicht fehl, prüft er nicht das Gemeinte. Sie hätten dann einen Test, der nichts absichert, und würden das nie merken.

12:11 Schritt eins ist ebenfalls unverzichtbar: Was Sie nicht reproduzieren können, können Sie nicht beheben, sondern nur hoffen. Und Schritt fünf ist die Kür, die sich fast immer lohnt: angrenzende Randfälle ergänzen, solange Sie ohnehin im Thema stecken. Und da ist er wieder — unser alter Bekannter aus Modul drei. Der Fehlerbericht sagt: Beete mit null Jahren erscheinen als „unbekannt" statt als „null Jahre".

12:35 Die Ursache steht in einer einzigen Zeile: Der Oder-Operator ersetzt jeden unwahren Wert, und die Null gehört dazu. Die Korrektur darunter ist ein Zeichen Unterschied. Ich zeige Ihnen diesen Fall zum dritten Mal in diesem Kurs, und das ist Absicht — er ist in echten Anwendungen so verbreitet, dass Sie ihn garantiert antreffen werden.

12:55 Und jetzt erkennen Sie ihn aus dem Fehlerbericht heraus, bevor Sie den Code gesehen haben. Halten Sie einen Fehler zuerst durch einen fehlschlagenden Test fest und beheben Sie ihn dann. Das Erfolgskriterium verlangt den Nachweis: Der Test muss vor der Korrektur nachweislich fehlgeschlagen sein. Danach ist er grün, und drei Randfälle sind zusätzlich abgedeckt.

13:16 Der Hinweis wiederholt die Regel, weil sie so leicht zu übergehen ist: Erst der rote Test, dann der Fix — sonst wissen Sie nicht, ob der Test greift. Diese Reihenfolge fühlt sich beim ersten Mal umständlich an. Nach dem dritten Mal möchten Sie es nicht mehr anders. Zuerst zu beheben und danach einen Test zu schreiben, der ohnehin grün ist, ist der Verstoß gegen die Kernregel — und der verbreitetste.

13:39 Der zweite Punkt betrifft die Gründlichkeit: Nur das gemeldete Symptom zu prüfen, lässt die Nachbarschaft ungesichert, wo derselbe Denkfehler oft noch einmal steckt. Der dritte klingt absurd und passiert trotzdem: den Test nach der Korrektur wieder zu entfernen, weil er ja jetzt grün ist. Genau dann fängt sein Nutzen erst an.

13:57 Und der vierte ist eine Suchrichtung — die Ursache im Aufrufer zu suchen, obwohl sie in der Funktion selbst sitzt.

Verhalten ist jetzt abgesichert

14:05 Drei Sätze zum Mitnehmen. Erstens: Ein Unit-Test prüft eine kleine Einheit gegen eine erwartete Ausgabe — je kleiner die Einheit, desto aussagekräftiger der Fehlschlag. Zweitens: Jest und Vitest unterscheiden sich im Umfeld, kaum in der Denkweise; was Sie hier gelernt haben, überträgt sich auf jedes Test-Framework. Und drittens die Regel, die den größten Unterschied macht: erst der fehlschlagende Test, dann die Korrektur — sonst prüft er nichts. Damit endet der dritte Tag.

14:34 Im nächsten Modul wird es anspruchsvoller: Es geht um asynchrones JavaScript.