Teststrategie für Angular-Anwendungen

Teststrategie für Angular

0:00 Bei Tests wird meistens die falsche Frage gestellt. Sie lautet gewöhnlich: Wie viel testen wir? Und die Antwort ist dann eine Prozentzahl, die niemandem hilft. Die richtige Frage ist: Auf welcher Ebene ist jede einzelne Aussage am billigsten zu haben? Denn jede Ebene kostet mehr als die darunter — an Laufzeit, an Pflege, an Verlässlichkeit.

0:21 In diesem Modul entscheiden wir für jedes Akzeptanzkriterium von Spurweite, wo es geprüft wird, und begründen die Wahl.

Qualität, Tests und zugängliche Oberflächen

0:29 Der vierte Tag steht unter dem Stichwort Qualität. Vormittags Tests — zuerst die Strategie, dann die Praxis. Nachmittags Barrierefreiheit und die Frage, mit welchen Bausteinen Sie eine Oberfläche bauen. Beides sind Themen, bei denen sich früh entscheidet, ob sie später teuer werden.

Was auf welcher Ebene geprüft wird

0:47 Beginnen wir mit der Einteilung. Vier Ebenen, und die Zuordnung einer Aussage zu einer Ebene ist eine Entwurfsentscheidung — keine Geschmacksfrage. Reine Logik prüfen Sie isoliert, ohne Angular. Das Verhalten einer Komponente samt Template mit dem Testwerkzeug von Angular. HTTP-Verhalten gegen die dafür vorgesehenen Werkzeuge.

1:08 Und wenige kritische Wege durch die ganze Anwendung im Browser. Der Satz, auf den es ankommt: Jede Ebene kostet mehr Laufzeit und mehr Pflege als die darunter. Nicht ein bisschen mehr — deutlich mehr. Ein Durchstich braucht eine laufende Anwendung, eine Datenbasis und oft einen Browser; eine Logikprüfung braucht eine Millisekunde.

1:29 Lesen Sie diese Pyramide von unten nach oben als Kostenkurve. Unten die fachlichen Regeln — schnell, stabil, billig. Darüber die Komponente mit ihrem Template. Dann HTTP. Und ganz oben der Durchstich, der alles zusammen prüft und entsprechend empfindlich ist. Die übliche Fehlform ist eine umgedrehte Pyramide: viele Durchstiche, wenige Logiktests.

1:51 Das passiert, wenn niemand die Ebene bewusst wählt, sondern jeder dort testet, wo der Code gerade liegt — und der liegt eben oft in der Komponente. Vier Gründe, und der dritte ist der, den man im Betrieb am meisten spürt: Fällt ein Test aus, soll die Ebene sagen, wo der Fehler sitzt. Ein roter Logiktest zeigt auf eine Regel.

2:12 Ein roter Durchstich zeigt auf — irgendetwas. Der erste Grund ist grundsätzlich: Eine fachliche Regel braucht keine gerenderte Ansicht, und wer sie trotzdem so prüft, zahlt ohne Gegenwert. Der zweite ist praktisch: Ein Durchstich für jede Regel macht die Suite langsam und brüchig. Und der vierte ist der wichtigste: Es ist eine Entwurfsentscheidung.

2:33 Der erste Punkt ist die umgedrehte Pyramide in einem Satz: Fachliche Regeln werden nur im Durchstich abgedeckt. Dann dauert die Suite zwanzig Minuten, und niemand lässt sie vor dem Einchecken laufen. Der zweite ist mechanisches Testen: Jede Komponente bekommt einen Test, auch die reine Anzeige — Aufwand ohne Aussage. Und der dritte ist der, der die Fehlersuche verlängert: Ein Test prüft drei Ebenen gleichzeitig und sagt bei Rot fast nichts darüber, was kaputt ist.

Vitest und Angular TestBed

3:01 Kommen wir zum Werkzeug. Da hat sich etwas geändert, und für die meisten ist es eine gute Nachricht. Neue Angular-Projekte bringen Vitest mit, dazu eine Browser-Nachbildung für den DOM. Der Testbefehl baut die Anwendung im Beobachtungsmodus und startet den Lauf. In der Projektkonfiguration steuern Sie, welche Dateien einbezogen werden, welche Vorbereitungsdateien laufen, wo gemeinsame Abhängigkeiten stehen und ob Abdeckung gemessen wird.

3:27 Der Einstiegspunkt für Komponententests bleibt das Testwerkzeug von Angular — daran hat sich nichts geändert, nur der Runner darunter ist ein anderer. Drei Varianten desselben Befehls, und der Unterschied ist wichtiger als er aussieht. Der erste läuft im Beobachtungsmodus und ist Ihr Alltag. Der zweite ist der für die Pipeline — ohne diese Flaggen wartet der Lauf dort endlos auf Änderungen, und der Build läuft in ein Zeitlimit.

3:52 Das ist ein Klassiker beim ersten Einrichten. Und die dritte Variante startet einen echten Browser; die brauchen Sie selten, aber wenn es um Layout oder echte Ereignisse geht, ist sie unverzichtbar. Eine kleine Datei mit großer Wirkung. Sie stellt bereit, was jeder Test braucht — hier die Testfassung des Datenzugriffs. Eingetragen wird sie einmal in der Projektkonfiguration, und ab dann gilt sie für alle Tests.

4:16 Worauf es ankommt: Ohne diese Stelle wiederholt sich dieselbe Vorbereitung in jeder Testdatei, und wenn sich etwas ändert, fasst man zwanzig Dateien an. Die Fußzeile nennt den Ort — und wir haben ihn in Modul zwei schon eingetragen, bevor es die Datei überhaupt gab. Der erste Punkt ist der, an dem eine Testsuite stirbt: Der Lauf dauert Minuten und wird deshalb übersprungen.

4:39 Erst vor dem Einchecken, dann gar nicht, dann sind drei Tests rot und niemand weiß seit wann. Der zweite ist die Wiederholung, von der ich eben sprach: Gemeinsame Vorbereitung steht in jeder Datei. Und der dritte ist der Pipeline-Klassiker: Der Beobachtungsmodus läuft im Build und wartet endlos — meistens erkennt man das an einem Job, der nach zwanzig Minuten abbricht.

Aussagekräftige Testfälle statt Coverage-Vorgabe

5:01 Jetzt zu dem Punkt, an dem ich am deutlichsten werden möchte. Es geht um die Zahl, die in vielen Projekten als Qualitätsmerkmal gilt und keines ist. Abdeckung misst, welche Zeilen durchlaufen wurden. Nicht, ob eine Aussage geprüft wurde. Sie können hundert Prozent erreichen, ohne eine einzige Erwartung zu formulieren — rufen Sie einfach alles auf und prüfen Sie nichts.

5:24 Ein Test dagegen benennt eine Erwartung, prüft beobachtbares Verhalten und schlägt fehl, wenn die Erwartung verletzt wird. Und das Schöne: Akzeptanzkriterien lassen sich direkt in Testnamen übersetzen. Wenn der Testname ein Satz ist, den auch ein Fachbereich versteht, sind Sie auf dem richtigen Weg. Fünf Schritte, und Schritt vier ist der, der den Unterschied macht: Prüfen, ob der Test bei bewusst falschem Code rot wird.

5:49 Das dauert dreißig Sekunden und beantwortet die einzige Frage, die zählt. Die Fußzeile sagt es drastisch, und ich meine es so: Ein Test, der bei falschem Code grün bleibt, ist teurer als kein Test — denn er erzeugt Sicherheit, die es nicht gibt. Schritt drei ist auch wichtig: Fehlerfall zuerst. Der Erfolgsfall funktioniert meistens ohnehin; die Ränder nicht.

6:11 Der erste Punkt ist der teuerste in der Pflege: Der Test prüft die Umsetzung und bricht bei jedem Umbau. Dann wird Refactoring unattraktiv, weil danach vierzig Tests angepasst werden müssen — und das ist genau das Gegenteil von dem, wofür Tests da sind. Der zweite ist die Folge einer Abdeckungsvorgabe: Tests ohne Erwartung, geschrieben, um eine Zahl zu erreichen.

6:32 Und der dritte ist die halbe Arbeit: Nur der Erfolgsfall ist abgedeckt, die Ränder nicht — und dort passieren die Fehler.

Ältere Karma- und Jasmine-Projekte einordnen

6:40 Bleibt der Bestand. Viele von Ihnen haben Testsuiten, die auf dem älteren Stack laufen. Die Frage ist, was damit passiert. Karma wird weiterhin unterstützt, und bestehende Suiten laufen weiter. Es gibt keinen Grund zur Eile. Für den Wechsel gibt es einen eigenen Migrationsleitfaden. Aber nicht alles lässt sich automatisch übernehmen, und einen Punkt sollten Sie sich merken: Die Funktion für simulierte Zeit gilt als veraltet und arbeitet nicht mit Vitest zusammen.

7:09 Tests, die darauf aufbauen, werden umgeschrieben, nicht übertragen. Jasmine-eigene Hilfsmittel brauchen ebenfalls ein Gegenstück. Fünf Schritte, und die Fußzeile nennt das Prinzip: Der Wechsel lohnt entlang ohnehin anstehender Arbeit, nicht als eigenes Projekt — dieselbe Regel wie bei den Formularen gestern. Schritt zwei ist wichtig: an einem kleinen Feature erproben, bevor man den Umfang kennt. Schritt drei ist die eigentliche Handarbeit.

7:35 Schritt vier ist der, der Sicherheit gibt: übergangsweise beide Läufe nebeneinander grün halten. Und Schritt fünf ist die Disziplin: Karma erst entfernen, wenn wirklich keine Datei mehr darauf zeigt. Der erste Punkt ist die klassische Fehlplanung: Die Umstellung beginnt beim größten und ältesten Testteil. Das ist der Bereich mit den meisten Eigenheiten und der geringsten Vertrautheit — schlechter kann man nicht anfangen.

8:00 Der zweite ist der, vor dem ich eben gewarnt habe: Tests mit simulierter Zeit werden übertragen statt umgeschrieben, und dann verhalten sie sich subtil anders. Und der dritte ist Übermut: Karma wird entfernt, bevor alles unter dem neuen Runner läuft.

Übung

8:14 Machen wir das für Spurweite. Und zwar zuerst auf dem Papier, dann im Code. Für Spurweite liegen die Akzeptanzkriterien der Auftragsbearbeitung vor: Ein gesperrter Auftrag darf nicht gespeichert werden, ein dringender braucht eine Begründung, und ein Serverfehler beim Speichern darf keine Eingaben verlieren. Dazu kommt der Aktualisierungsfehler im Auswahlzustand aus Modul fünf — den haben wir damals behoben, aber nie abgesichert. Genau der wird jetzt unser erster Test.

8:43 Das Lernziel ist die Zuordnung selbst: für gegebene Akzeptanzkriterien die günstigste Prüfebene bestimmen. Das Erfolgskriterium hat zwei Teile, und der zweite ist der wichtigere: Der Test zum Aktualisierungsfehler ist ohne die Behebung rot. Das ist die Gegenprobe — nehmen Sie die Behebung testweise zurück und schauen Sie zu, wie der Test rot wird.

9:04 Wer früh fertig ist, benennt ein Kriterium, für das sich ein Test nicht lohnt, und begründet das. Diese Übung ist anspruchsvoller, als sie klingt. Der erste Schritt ist der, den man überspringen möchte: die Kriterien auflisten, ohne Technik. Machen Sie es trotzdem, denn danach ist die Zuordnung fast offensichtlich. Schritt zwei ist die eigentliche Entscheidung. Schritt drei formuliert den Testfall als Satz. Schritt vier schreibt ihn. Und Schritt fünf ist die Gegenprobe.

9:33 Die Reihenfolge ist Absicht — wer mit dem Code anfängt, landet automatisch auf der Ebene, auf der der Code gerade liegt. Der erste Punkt ist genau das: Alle Kriterien landen auf der Komponentenebene, weil sie vertraut ist. Der zweite ist der, der die ganze Suite entwertet: Der Test wird grün geschrieben und nie gegen falschen Code geprüft.

9:54 Und der dritte ist eine Verwechslung: Die Strategie nennt Werkzeuge statt Aussagen — „wir benutzen Vitest" ist keine Teststrategie. Im nächsten Modul setzen wir das um und schreiben Tests auf drei Ebenen.