Komponenten-, HTTP- und E2E-Tests schreiben

Komponenten-, HTTP- und E2E-Tests

0:00 Ein guter Komponententest liest sich wie eine Bedienungsanleitung. Kein einziger Blick in die Klasse: Fülle das Feld aus, setze den Haken, drücke den Knopf, und dann steht da das. Wenn Sie einen Test lesen und dabei nicht verstehen, was der Benutzer tut, dann prüft er vermutlich Interna — und wird beim nächsten Umbau rot, ohne dass ein Fehler vorliegt.

0:20 In diesem Modul schreiben wir Tests auf drei Ebenen, und die Auswahl haben wir gestern schon getroffen.

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

0:26 Wir bleiben beim Thema Qualität. Die Strategie steht, jetzt die Praxis: Komponenten, HTTP und genau ein Durchstich. Danach wenden wir uns der Oberfläche zu — und der Frage, ob sie ohne Maus überhaupt benutzbar ist.

Komponenten- und Interaktionstests

0:41 Fangen wir bei der Komponente an. Und gleich mit der Perspektive, die alles Weitere bestimmt: Sie testen aus Sicht der Bedienung, nicht aus Sicht der Klasse. Das Testwerkzeug von Angular konfiguriert die Umgebung, daraus entsteht eine Halterung für die Komponente. Eingaben setzen Sie über eine eigene Methode, Elemente finden Sie über Abfragen, Ereignisse lösen Sie aus.

1:03 Auf asynchrone Aktualisierung warten Sie mit dem Warten auf Stabilität — und das ist ab jetzt der einzige Weg, denn die Funktion mit simulierter Zeit gilt als veraltet und arbeitet mit dem neuen Runner nicht zusammen. Wer aus älteren Projekten kommt, muss sich diese eine Gewohnheit abgewöhnen. Der Ablauf ist immer derselbe: aufbauen, Eingabe setzen, auf Stabilität warten, Element finden, Ereignis auslösen.

1:27 Worauf es ankommt, steht in der Fußzeile: ein eigenes Testattribut statt einer CSS-Klasse. Eine Klasse dient der Gestaltung und wird geändert, wenn sich die Gestaltung ändert — dann bricht Ihr Test, obwohl fachlich nichts passiert ist. Ein Attribut, das ausdrücklich für Tests da ist, überlebt Umbauten. Das ist eine Konvention, die man einmal im Team festlegt und dann durchhält.

1:51 Vier Dinge, und sie haben eines gemeinsam: Nichts davon ist Verhalten. Private Felder und interne Methoden sind Umsetzung. Die Reihenfolge interner Aufrufe ist Umsetzung. CSS-Klassen, die der Gestaltung dienen, sind Umsetzung. Und die Anzahl der Durchläufe der Change Detection ist erst recht Umsetzung — die ändert sich, sobald jemand eine Ableitung anders schneidet.

2:13 Wenn Sie einen dieser vier Punkte in einem Test finden, ist das ein guter Anlass, ihn umzuschreiben, bevor er Sie das nächste Mal aufhält. Der erste Punkt ist der häufigste: Der Test greift auf die Komponenteninstanz zu und prüft Interna. Das ist verführerisch, weil es so einfach ist — die Instanz liegt ja direkt vor einem.

2:33 Der zweite ist der, der unzuverlässige Tests erzeugt: Auf die Aktualisierung wird nicht gewartet. Manchmal geht es gut, manchmal nicht, und dann sucht man nach einem Fehler in der Anwendung, der gar keiner ist. Und der dritte ist der eben besprochene: Ein Selektor hängt an einer Gestaltungsklasse.

Test Harnesses für wiederkehrende Bausteine

2:51 Jetzt zu einem Muster, das sich erst ab dem dritten Test auszahlt — und dann sehr deutlich. Ein Harness kapselt, wie ein Baustein bedient und ausgelesen wird. Der Test sagt dann „öffnen" oder „wähle Eintrag", statt Selektoren und Ereignisse zu kennen. Ändert sich die Oberfläche, ändert sich das Harness — nicht jeder Test. Denken Sie an eine Fernbedienung.

3:14 Sie drücken „lauter", und ob das Gerät intern eine Taste, einen Regler oder einen Sensor hat, geht Sie nichts an. Angular liefert für einige eigene Bausteine fertige Harnesses mit, etwa für Routing-Tests. Vier Anzeichen, und wenn zwei zutreffen, lohnt es sich. Der Baustein wird in vielen Tests bedient — bei einem einzigen wäre es Aufwand ohne Gegenwert.

3:36 Seine Bedienung besteht aus mehreren Schritten, also Feld füllen, Ereignis auslösen, warten. Seine Oberfläche steht noch nicht fest, was bei neuen Features meistens der Fall ist. Und der vierte ist der, der mir beim Lesen am meisten bringt: Der Test soll die Absicht zeigen, nicht die Mechanik. Ein Test, der aus fünf Bedienschritten besteht, liest sich besser als einer aus fünfzehn Zeilen Ereignisarbeit.

4:01 Der erste Punkt ist die Übertreibung: Für jeden Baustein entsteht ein Harness, auch für den einmal benutzten. Dann haben Sie eine zweite Codebasis, die auch gepflegt werden will. Der zweite hebt den Nutzen wieder auf: Das Harness gibt interne Elemente nach außen — dann kennen die Tests doch wieder die Struktur. Und der dritte ist die Erosion: Die Tests umgehen das Harness für einen Sonderfall. Einmal ist verständlich, dreimal und es hat seinen Zweck verloren.

HTTP-Verhalten prüfen

4:28 Kommen wir zur nächsten Ebene. Und zu einer Methode, die man am Ende jedes Tests aufrufen sollte und die viele nicht kennen. Die Testfassung ersetzt die echte Übertragung. Sie erwarten Anfragen, beantworten sie und prüfen am Ende, dass nichts offen blieb. Fehler stellen Sie nach — entweder mit einer Antwort samt Statuscode oder als Netzfehler.

4:48 Ein Detail ist wichtig und kostet sonst eine halbe Stunde Fehlersuche: Wenn Sie eigene Interceptors prüfen, muss der echte Datenzugriff vor der Testfassung bereitgestellt werden. Die Dokumentation warnt ausdrücklich davor, das zu vertauschen. Vier Anweisungen, und die letzte ist die, um die es mir geht. Die Prüfung am Ende deckt auf, wenn eine Ansicht mehr Anfragen stellt als gedacht — etwa weil ein Abruf zweimal läuft oder ein Interceptor einen zusätzlichen auslöst.

5:17 Das ist eine Fehlerklasse, die sonst nur als merkwürdige Last auf dem Server auffällt, meistens Monate später. Die Zeile kostet nichts und findet etwas, wonach niemand sucht. Gewöhnen Sie sie sich an. Der erste Punkt ist genau das: Die abschließende Prüfung fehlt, überzählige Anfragen bleiben unbemerkt. Der zweite ist der, vor dem ich gerade gewarnt habe: Die Reihenfolge der Provider ist vertauscht, und der Interceptor greift nicht — der Test ist dann grün und prüft nichts.

5:45 Und der dritte ist die halbe Arbeit: Nur der Erfolgsfall wird beantwortet, der Fehlerpfad bleibt ungeprüft. Dabei ist genau der Fehlerpfad der Grund, warum man HTTP überhaupt auf dieser Ebene testet.

E2E-Tests für wenige kritische Wege

5:57 Bleibt die teuerste Ebene. Und die Kunst besteht darin, sie klein zu halten. Ein Durchstich führt durch die laufende Anwendung im Browser. Er ist langsam, hängt von Umgebung und Daten ab und ist anfällig für Zufallsfehler. Das ist keine Kritik, sondern eine Eigenschaft — er prüft eben wirklich alles zusammen. Deshalb deckt er wenige Wege ab: die, deren Ausfall das Geschäft trifft.

6:22 Und keine Regeln, die eine Ebene darunter prüfbar sind. Die Faustregel, die ich Ihnen mitgebe: Wenn Sie eine Aussage auch ohne Browser prüfen können, dann tun Sie es. Fünf Schritte, und der erste ist die einzige Frage, die zählt: Welcher Ablauf hält den Betrieb an, wenn er bricht? Bei Falkenhorst ist das der Weg vom Suchen bis zum Speichern — bricht er, kann die Werkstatt nicht arbeiten. Alles andere ist ärgerlich, aber nicht existenziell.

6:49 Daraus folgen höchstens eine Handvoll Wege. Und der fünfte Schritt ist der, den man aufschreiben sollte: eine Laufzeitgrenze für die Suite. Die Fußzeile sagt warum — wächst die Zahl der Durchstiche, sinkt die Bereitschaft, sie überhaupt laufen zu lassen. Der erste Punkt ist die umgedrehte Pyramide von gestern, hier in ihrer Endform: Jede Regel bekommt einen Durchstich, und die Suite läuft eine halbe Stunde.

7:13 Der zweite ist die Reaktion auf Zufallsfehler, die alles schlimmer macht: Sie werden mit Wartezeiten übertüncht statt behoben. Jede eingebaute Wartezeit macht die Suite langsamer und den nächsten Zufallsfehler wahrscheinlicher. Und der dritte ist ein Pflegeproblem: Der Durchstich prüft Texte, die sich regelmäßig ändern.

Übung

7:32 Sichern wir den wichtigsten Ablauf von Spurweite ab — verteilt auf drei Ebenen, mit genau einem Durchstich. Der wichtigste Ablauf ist: einen Auftrag suchen, öffnen, bearbeiten und speichern. Beim Speichern kann der Server ablehnen, weil der Auftrag zwischenzeitlich gesperrt wurde — das passiert in der Praxis, wenn zwei Standorte am selben Fahrzeug arbeiten.

7:53 Und dann darf auf keinen Fall passieren, was in der ersten Fassung passiert ist: dass die Eingaben verloren gehen. Wer zehn Minuten einen Bericht getippt hat und ihn durch eine Ablehnung verliert, benutzt die Anwendung danach anders. Das Lernziel ist die Verteilung selbst — Prüfaufgaben auf drei Ebenen verteilen und die Verteilung begründen.

8:12 Das Erfolgskriterium nennt drei Teile, und der dritte ist der, den man gern weglässt: die Begründung schriftlich. Warum genau ein Durchstich und nicht zwei? Diese Frage werden Sie in Ihrem Projekt beantworten müssen, und es hilft, sie einmal geübt zu haben. Wer früh fertig ist, ergänzt ein Harness für das Formular und stellt zwei Tests darauf um — und sieht dann selbst, wie viel kürzer sie werden.

8:36 Der erste Schritt ist wieder der auf dem Papier: den Ablauf zerlegen, je Schritt die Ebene bestimmen. Dann drei Runden Code — Komponente, HTTP, Durchstich. Achten Sie beim zweiten Schritt darauf, wirklich ohne Interna auszukommen; das ist die Disziplin, um die es geht. Und Schritt fünf ist der, der aus einer Übung eine Entscheidung macht: begründen, warum kein zweiter Durchstich nötig ist.

9:00 Wenn Ihnen dazu nichts einfällt, ist der erste vielleicht auch schon zu breit. Der erste Punkt ist die verbreitetste Fehlverteilung: Der Durchstich prüft auch die Validierungsregeln. Er kann das — und dafür brauchen Sie ihn nicht. Der zweite ist der halbe HTTP-Test: Die Anfrage wird beantwortet, aber die Reaktion der Ansicht nicht geprüft.

9:21 Dann wissen Sie, dass gerufen wurde, nicht aber, was der Benutzer sieht. Und der dritte ist der, der den fachlichen Kern verfehlt: Das Speichern wird geprüft, der Verlust der Eingaben bei Ablehnung nicht. Im nächsten Modul geht es um Oberflächen, die auch ohne Maus funktionieren.