Eine weiche Prüfung braucht trotzdem einen festen Stopp.
Sammle unabhängige Fehler, ohne dass eine fehlgeschlagene Voraussetzung die nächste Aktion freigibt.
Übersetzte Ausgabe. Technische Kennungen bleiben in ihrer ursprünglichen Form.
Eine Prüfseite hat einen falschen Titel und einen falschen Entwurfsstatus. Eine normale Assertion stoppt beim ersten Fehler, eine weiche kann beide sammeln. Das hilft der Diagnose, doch der Test bleibt fehlgeschlagen. Fortgesetzte Ausführung erlaubt nicht automatisch den nächsten Produktschritt.
Dieser Leitfaden nutzt die Playwright-Assertionsdokumentation mit einer erfundenen lokalen Seite. Keine echte Freigabe, Übermittlung oder Kontoaktion. Unabhängige Beobachtungen gehen einem Tor vor dem nächsten Demo-Schritt voraus.
Sammle weiterhin sinnvolle Beobachtungen
Fehlgeschlagene weiche Assertions beenden die Ausführung nicht, markieren aber den Test als fehlgeschlagen. Sie arbeiten mit dem Playwright-Testläufer, nicht automatisch mit einer anderen Bibliothek.
Die nächste Beobachtung muss nach dem ersten Fehler noch sinnvoll sein. Ein falscher Titel verhindert keinen unabhängigen Statuscheck. Ein fehlender Ausgangsdatensatz ist anders: Seine Felder erzeugen womöglich nur Folgefehler.
await expect.soft(page.getByRole('heading')).toHaveText('Review demo draft');
await expect.soft(page.getByRole('status')).toHaveText('Ready for review');
expect(test.info().errors).toHaveLength(0);
await page.getByRole('button', { name: 'Continue demo' }).click();Das Beispiel verlangt die kontrollierte Seite und importierte test und expect. Die feste Fehlerprüfung ist beabsichtigt. Bei einem weichen Fehler wird Continue nicht geklickt. Das lokale Label ist keine Regel für reale Freigaben.
Setze das Tor vor abhängige Aktionen
Stoppe vor einer Aktion, deren Bedeutung vom geprüften Zustand abhängt. Am Ende wäre es zu spät: Der falsche Datensatz könnte bereits verändert sein. Wähle nach Abhängigkeiten, nicht nach möglichst vielen Fehlermeldungen.
Fehler stehen in test.info().errors. Leere dieses Array nicht und ändere keinen Status, um Erfolg vorzutäuschen. Ein späterer Screenshot löscht die Fehler nicht.
Weitere Leseprüfungen müssen sinnvoll und erlaubt bleiben. Auch Lesen kann private Daten in Traces zeigen. Nutze erlaubte Testdatensätze und prüfe Dateien vor dem Teilen.
Prüfe auch den negativen Fall
Die lokale Vorlage hat zwei falsche Angaben. Der Läufer behält beide Fehler; das feste Tor stoppt. Eine Nachprüfung bestätigt, dass der Continue-Button nie seinen Zustand änderte. Der absichtliche Fehlversuch bleibt ein Fehler, kein Produktionspass.
Ein anderer Fall mit korrekten Angaben passiert das Tor und ändert einen lokalen Marker. Das belegt Kontrollfluss, keine Serverabsicherung und keine universelle Eigenschaft generierter Tests.
Bei einer Sicherheitsvoraussetzung kann eine normale harte Assertion einfacher sein. Weichheit ist ein Diagnosewerkzeug, kein Zwang, jeden Fehler aufzuschieben. Nutze beide Formen passend.
Hinterlasse eine Prüfregel
Notiere unabhängige Checks, abhängige Aktion und Stoppstelle. So erkennt man einen Ablauf, der Fehler sammelt und trotzdem weiterhandelt.
AnyTest beschreibt Erkundung und Ende-zu-Ende-Tests für menschliche Prüfung. Frage, ob der Test seinen Fehler behält und abhängige Aktionen schützt. Keine besondere AnyTest-Implementierung wird behauptet. Mehr Diagnose darf die Grenze nicht schwächen.
Häufige Fragen
Bleibt ein Test nach einer weichen Fehlprüfung grün?
Nein. Die Ausführung läuft weiter, aber der Test gilt als fehlgeschlagen.
Wo gehört das feste Tor hin?
Vor die abhängige Aktion, nicht erst ans Ende.