Was wirklich UI-Testing braucht
Der Ablauf funktioniert von Anfang bis Ende. Ein Nutzer kommt von der Absicht zum Ergebnis. Keine Ebene unterhalb der Oberfläche kann das beantworten.
Zustand über mehrere Schritte hinweg. Was auf einem Screen gesetzt wird, gilt auch auf dem nächsten. Hier häufen sich die echten Fehler.
Was dem Nutzer angezeigt wird, entspricht dem, was tatsächlich passiert ist. Eine Erfolgsmeldung ohne gespeicherten Datensatz ist die häufigste Lüge, die eine Anwendung erzählt.
Was nicht in einen UI-Test gehört
Validierungsregeln
Jede Kombination fehlerhafter Eingaben über den Browser zu prüfen, ist langsam und fragil.
Prüfen Sie eine davon in der UI, den Rest über die API.
Berechnungen
Ein Unit-Test beantwortet das in Millisekunden – mit einer besseren Fehlermeldung.
Testdaten anlegen
Sich durch fünf Screens zu klicken, um eine Fixture zu erzeugen, ist langsam und bricht aus Gründen, die mit dem Testgegenstand nichts zu tun haben.
Die richtige Größe der Suite
Zwei nützliche Regeln. Wählen Sie die abgedeckten Abläufe danach aus, wie unbemerkt sie ausfallen würden, und nicht nach ihrer Wichtigkeit – denn wichtige Abläufe werden beobachtet, unauffällige nicht. Und hören Sie auf, weitere hinzuzufügen, sobald der Wartungsaufwand die Zeit auffrisst, die Sie eigentlich sparen wollten. Das passiert früher, als die meisten Teams erwarten.
Die drei Gewohnheiten
Stabile Anker statt CSS-Pfade. Beseitigt die meisten Brüche durch Redesigns.
Warten Sie auf Zustände, nicht auf Zeit. Beseitigt den größten Teil der Instabilität.
Prüfen Sie das, was ein Neuladen bestätigen würde. Beseitigt die trügerische Sicherheit einer Erfolgsmeldung.
Einen Test eine Ebene tiefer verschieben – in der Praxis
Dem Rat, Prüfungen unterhalb der Oberfläche anzusiedeln, stimmt man leicht zu, doch er bleibt vage in der Umsetzung. Deshalb hier ein konkretes Beispiel.
Sie haben einen Browser-Test, der ein Registrierungsformular mit vierzehn verschiedenen ungültigen Eingaben ausfüllt und jedes Mal die Fehlermeldung prüft. Er braucht vier Minuten, bricht bei jeder Änderung des Formularlayouts und sagt fast nichts über den Browser aus.
Ersetzen Sie ihn durch einen Browser-Test, der eine ungültige Eingabe abschickt und bestätigt, dass dem Nutzer ein Fehler angezeigt wird, plus dreizehn API-Tests, die die Validierungsregeln direkt prüfen. Der Browser-Test beantwortet nun eine Browser-Frage, die Regeln sind schneller und präziser abgedeckt, und eine Änderung an der Validierung erfordert keinen Eingriff mehr in irgendetwas, das gerendert wird.
Was sich mit Disziplin allein nicht beheben lässt
Selektoren
Ein Redesign, das funktional nichts ändert, färbt die Suite rot.
Hier verschwindet der größte Teil der Wartungszeit.
Warten
Feste Wartezeiten sind langsam und trotzdem instabil. Korrektes Warten setzt voraus, dass man weiß, worauf man wartet.
Der größte Teil der Instabilität lässt sich hierauf zurückführen.
Von Hand erstellte Abdeckung
Abgedeckt ist, was jemand geschrieben hat – also die interessanten Abläufe und nicht die, die kaputtgehen.
Der dritte Punkt ist struktureller Natur. Eine Abdeckung, die durch die Zeit ihrer Autoren begrenzt ist, fällt hinter ein Produkt zurück, dessen Code zunehmend von einem Agenten stammt. Absichtsbasierte Schritte und generierte Abdeckung setzen genau dort an.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Das Dashboard deckt dasselbe für alle ab, die keine lokale Installation möchten, und den vollständigen Befehlsumfang finden Sie im CLI-Repository.
Verbinden Sie das Repository über das Dashboard, und die Testläufe starten aus dem Deployment, das Sie ohnehin erzeugen – oder fügen Sie stattdessen einen Schritt in Ihren eigenen Workflow ein.
Was TestSprite auf jeder Ebene abdeckt
Abläufe im Browser, dort wo nur ein Browser antworten kann, und die darunterliegende API-Ebene im selben Projekt. Genau das macht den Rat, Prüfungen nach unten zu verschieben, praktikabel statt bloß wünschenswert: Die Validierungsregeln wandern in API-Fälle, die in Sekunden laufen, und ein Browser-Fall prüft, dass das Formular daran angebunden ist.
Beides wird aus Ihrem Produkt generiert und in natürlicher Sprache verfeinert, und Browser-Schritte sind Absichten statt Selektoren. So übersteht die Suite Redesigns, die funktional nichts ändern.
Am Ende steht eine Browser-Suite, die klein genug ist, dass ihr im Team vertraut wird, und die die entscheidenden Abläufe abdeckt – während Regeln und Sonderfälle eine Ebene tiefer schneller geprüft werden.
Wie viele UI-Tests sind richtig?
Genug, um die Abläufe abzudecken, deren Ausfall Ihnen peinlich wäre – ausgewählt danach, wie unbemerkt sie ausfallen würden. Alles andere verschieben Sie eine Ebene tiefer.
Sollten wir jeden Screen testen?
Nein. Testen Sie Abläufe, nicht Screens. Ein Screen, durch den kein Ablauf führt, rechtfertigt selten einen Browser-Test.
Was ist mit Barrierefreiheit?
Die mechanischen Prüfungen lohnt es sich zu automatisieren, der Rest braucht eine menschliche Bewertung. Ein eigenes Thema mit eigenem Tooling.
Ist Cross-Browser-Abdeckung notwendig?
Das hängt von Ihren Analytics-Daten ab. Viele Teams lassen eine vollständige Suite auf einem Browser laufen und eine Smoke-Suite auf den übrigen – meist ist das der richtige Kompromiss.
Wann sollten UI-Tests laufen?
Bei jedem Pull Request. Alles Seltenere führt dazu, dass ein Fehlschlag auf ein ganzes Bündel von Änderungen zeigt statt auf eine einzelne.
Testen Sie Abläufe in der UI, alles andere darunter.
UI-Testing sollte durchgängige Abläufe abdecken, den Zustand über mehrere Schritte hinweg und die Frage, ob das, was dem Nutzer angezeigt wird, dem entspricht, was tatsächlich passiert ist. Validierung, Berechnungen und das Anlegen von Testdaten gehören eine Ebene tiefer, wo sie schneller und leichter zu diagnostizieren sind.