UI-Testing mit Puppeteer: Der Praxisleitfaden

Wofür sich UI-Testing mit Puppeteer wirklich eignet

• Direkte Browsersteuerung. Screenshots, PDFs, Netzwerk-Interception, Performance-Traces. Wenn der Browser etwas Bestimmtes tun soll, ist das der kürzeste Weg.

• Scraping und Automatisierung. Ein großer Teil der Puppeteer-Nutzung hat mit Testen gar nichts zu tun – und darin ist Puppeteer ausgezeichnet.

• Ein kleiner, erlernbarer Funktionsumfang. Sie können die gesamte API im Kopf behalten, und das ist seltener, als es sein sollte.

Die drei Kostenfaktoren einer Browser-Suite

• Selektoren brechen. Ein Redesign, das funktional nichts ändert, färbt die Suite rot. Hierhin fließt tatsächlich der Großteil der Wartungszeit.

• Warten ist tückisch. Feste Wartezeiten sind langsam und trotzdem instabil; korrektes Warten setzt voraus, dass Sie wissen, worauf Sie warten. Die meisten instabilen Tests lassen sich darauf zurückführen.

• Abdeckung entsteht von Hand. Sie decken ab, was jemand geschrieben hat – also die Abläufe, die interessant waren, und nicht die, die kaputtgehen.

Entscheiden, was automatisiert wird

Der Instinkt sagt: mit dem wichtigsten Feature anfangen. Das bessere Kriterium ist, wie leise etwas ausfallen würde. Ein kaputter Checkout ist laut, davon erfahren Sie innerhalb einer Stunde. Ein kaputter Export, eine kaputte Einladung oder eine kaputte Einstellungsseite ist leise, und genau diese leisen Ausfälle lohnt es sich zuerst zu automatisieren.

Zweites Kriterium: Wie oft ändert es sich? Ein Ablauf, der sich in jedem Sprint ändert, kostet mehr Wartung, als er einbringt. Decken Sie ihn später ab, wenn er sich stabilisiert hat.

Drei Gewohnheiten, die am meisten Zeit sparen

• Verwenden Sie stabile Attribute. Ein eigenes Test-Attribut statt eines CSS-Pfads. Diese eine Änderung beseitigt den Großteil der Redesign-Brüche.

• Warten Sie auf Zustände, nicht auf Zeit. Warten Sie auf das Element oder die Antwort, niemals auf eine Anzahl Millisekunden.

• Prüfen Sie etwas, das ein Reload bestätigen würde. Eine Erfolgsmeldung ist kein Beleg dafür, dass etwas tatsächlich gespeichert wurde.

Wo intentionsbasierte Verifikation ihren Platz hat

Brechende Selektoren und handgeschriebene Abdeckung sind strukturelle Probleme und nicht mit mehr Disziplin zu beheben. Ein Schritt, der als Absicht formuliert ist, übersteht ein Redesign, an dem ein Selektor scheitert, und eine Abdeckung, die aus Ihrem Produkt statt aus dem Gedächtnis einer Person entsteht, enthält Abläufe, die niemand geschrieben hätte.

Das ist kein Argument gegen Puppeteer, das für die direkte Browsersteuerung das richtige Werkzeug bleibt. Es ist ein Argument dagegen, die Breite von Hand zu schreiben.

Wenn Sie lieber nichts installieren möchten, leistet das Dashboard dasselbe. Alles Weitere, was die Kommandozeile kann, finden Sie im CLI-Repository.

Die drei Dinge, die ein Puppeteer-Skript brüchig machen

Schnell geschriebene Skripte brechen aus denselben drei Gründen, und für jeden gibt es eine Lösung, die im Moment nichts kostet und später sehr viel.

Verkettete CSS-Pfade sind der erste. Ein Selektor, der sich über vier Strukturebenen hangelt, kodiert das Layout und nicht das Element, also bricht ihn jeder Wrapper, den irgendjemand einfügt. Verankern Sie ihn an etwas, das beschreibt, was das Element ist, nicht wo es sitzt.

Feste Wartezeiten sind der zweite. Eine Verzögerung, die an einem langsamen Tag zuverlässig ist, bezahlen Sie an jedem schnellen Tag mit, und am langsamsten Tag scheitert sie trotzdem. Warten Sie auf das Element, die Antwort oder den Zustandswechsel.

Der dritte ist, genau das zu prüfen, was Sie gerade getan haben. Auf Speichern zu klicken und anschließend zu prüfen, ob es den Speichern-Button gibt, beweist nichts. Die Prüfung muss etwas sein, das nur dann zutrifft, wenn die Operation wirklich abgeschlossen wurde, und das bedeutet meist, das Objekt erneut abzurufen.

Bei jeder Änderung ausführen

Wenn die Pipeline einem anderen Team gehört, ist die GitHub App der Weg des geringsten Widerstands: Sie ist ein Webhook, ändert nichts in Ihrem Repository und wird ausgelöst, sobald Ihr Build die neue Version als live meldet. Wenn Sie den Check stattdessen im Repository sichtbar haben möchten, erledigt das ein GitHub Actions -Schritt.

Wo TestSprite neben Puppeteer seinen Platz hat

Puppeteer bleibt für die direkte Browsersteuerung: Screenshots, PDFs, Netzwerk-Interception, Scraping. TestSprite übernimmt den Teil, der nicht mit der Schreibzeit skaliert, nämlich zu entscheiden, was abgedeckt wird, und das Abgedeckte am Leben zu halten.

Schritte werden als Absichten statt als Selektoren gespeichert, was den Großteil der Redesign-Brüche beseitigt, und das Warten wird übernommen, statt dass Sie es pro Test justieren. Die Abdeckung wird aus Ihrem Produkt generiert, sodass auch die leisen Abläufe enthalten sind, die es auf niemandes Liste schaffen würden.

Was das in der Praxis ändert: Der Anteil roter Builds, hinter denen echte Fehler stecken, bleibt hoch genug, dass die Leute sie weiterhin lesen, und genau das entscheidet darüber, ob eine Browser-Suite ihr zweites Jahr übersteht.