Ein erwarteter Fehler führt den Test trotzdem aus.

Ein Team überspringt einen bekanntermaßen fehlschlagenden Test. Sein Körper läuft nicht mehr; der Bericht zeigt nicht, ob der Defekt noch reproduzierbar ist. Playwright hat eine Annotation für erwartetes Fehlschlagen: der Test läuft, ein Erfolg wird unerwartet.

Der Annotationsleitfaden unterscheidet skip(), fail() und fixme(). skip läuft nicht; fail läuft und erwartet einen Fehler. fixme ist für Fälle beschrieben, deren Ausführung langsam ist oder abstürzt. Wählen Sie nach Bedeutung und Betriebsgrenzen.

Das Beispiel eng halten

Unser Beispiel vergleicht zwei feste Zeichenfolgen. Die Abweichung ist absichtlich, ohne echten Produktdefekt, Browseraktion oder Account. Ein anderes Beispiel gleicht die Zeichenfolgen an und behält fail: unerwarteter Erfolg und ein Runner-Exitcode ungleich null.

import { test, expect } from '@playwright/test';

test('controlled expected mismatch', async () => {
  test.fail(true, 'Invented mismatch for annotation demonstration');
  expect('actual demo value').toBe('expected demo value');
});

Verwenden Sie den Playwright-Testrunner, nicht gewöhnliche JavaScript-Ausführung. Der Bericht behält Assertionfehler und erwarteten Status. Ein erfolgreicher Runner-Exit bedeutet hier, dass der Fehler zur Erwartung passte, nicht dass die Zeichenfolgen gleich waren.

Den tatsächlichen Fehler prüfen

Die Annotation bindet den Fehler nicht an eine bestimmte Assertion. Scheitert das Setup zuerst, kann der erwartete Status erfüllt sein, ohne den Defekt zu erreichen. Vereinfachen Sie Setup, lesen Sie den Fehler und dokumentieren Sie die ausgeführte Assertion. Unerwartete Authentifizierungs- oder Umgebungsfehler sind kein Beleg für den bekannten Defekt.

Für einen echten Fall erhalten Sie das korrekte Sollverhalten in der Assertion sowie einen überprüfbaren Issuebezug und Verantwortlichen. Schreiben Sie die Assertion nicht zur Akzeptanz des Defekts um. Unser Beispiel erfindet keine Issuelinks und verwendet nur eine Beschreibung.

Bedingte Annotationen gehören zur betroffenen Konfiguration. Ein Fehler nur in einem Browser rechtfertigt kein bedingungsloses fail für alle. Prüfen Sie Bedingung und erwarteten Status mit den Testeingaben, statt sie in einem entfernten Helfer zu verstecken.

Unerwarteten Erfolg überprüfen

Ein Erfolg kann eine Reparatur, einen anderen Pfad oder eine schwächere Assertion bedeuten. Prüfen Sie vor Entfernen der Annotation. Nach bestätigtem Sollverhalten erhalten Sie normale erfolgreiche Abdeckung statt einer dauerhaften Ausnahme.

Unser Runner unterscheidet absichtliche erwartete Abweichung, unerwarteten Erfolg gleicher Zeichenfolgen und einen nicht ausgeführten übersprungenen Körper. Das prüft Annotationen, keine Releasebereitschaft.

Unsichere oder teure Ausführung braucht eine eigene Entscheidung. fail erlaubt weder destruktive Aktionen noch Kosten oder Produktionsdaten. Benennen Sie übersprungene Abdeckung und fehlende Verifikation.

AnyTest beschreibt Tests für menschliches Review. Prüfen Sie Ausnahmen wie Assertions und Setup. Eine bestimmte AnyTest-Defektintegration wird nicht behauptet. Echte Ausnahmen brauchen einen Verantwortlichen und nächsten Prüftermin.