Benenne Testschritte nach ihrer Frage.

Ein Bericht sagt Schritt 1 bestanden, Schritt 2 bestanden, Schritt 3 fehlgeschlagen. Er bewahrt Reihenfolge, erklärt wenig. Ein anderer sagt Erfolgreich gespeichert, obwohl nur geklickt wurde. Das Label behauptet eine nie geprüfte Schlussfolgerung.

Dieser Leitfaden nutzt die Playwright-Test-API für eine erfundene lokale Einstellung. Kein Konto, kein Server. Berichtsgrenzen sollen zu Fragen des Codes passen, ohne Namen in Beweise zu verwandeln.

Gib jedem Schritt eine prüfbare Frage

test.step gruppiert Aktionen in benannten Berichtsschritten. Der Name beschreibt Absicht; die antwortende Assertion gehört hinein. Aktuelle Einstellung lesen ist ehrlicher als Dauerhaft gespeichert, wenn nur eine Seite geprüft wird.

await test.step('Read the current demo preference', async () => {
  await expect(page.getByRole('status')).toHaveText('Demo preference: off');
});
await test.step('Enable the local demo preference', async () => {
  await page.getByRole('button', { name: 'Enable demo preference' }).click();
  await expect(page.getByRole('status')).toHaveText('Demo preference: on');
});

Die kontrollierte Vorlage und importierte test und expect werden vorausgesetzt. Geprüft werden lokaler Anfangs- und Änderungszustand, keine Serverpersistenz. Titel, Schritte und Screenshot sollen diese Grenze halten.

Trenne Vorbereitung und Beleg

Öffnen bereitet vor. Anfangszustand lesen liefert Beleg. Klicken handelt; neuen Zustand beobachten liefert weiteren Beleg. Alles als Einstellungsablauf abschließen zu benennen versteckt den Fragenwechsel.

Zu viele Kleinstschritte stören ebenfalls. Jeder Locator braucht keinen eigenen Schritt. Gruppiere nach sinnvoller Frage, nicht nach Zeilen oder gewünschter Anzahl.

Verschachtelung kann echte Hierarchie zeigen, darf aber Assertions nicht unter vagen Namen verbergen. Der Prüfer soll den Check ohne Kette aus Vorbereiten, Verarbeiten und Fertigstellen finden.

Gib nur benötigte Werte zurück

Die API dokumentiert den Callback-Rückgabewert von test.step. So bleibt eine kontrollierte Kennung bei ihrem Ursprung. Übergib nur Nötiges, statt Schrittgrenzen als globalen versteckten Speicher zu nutzen.

Validiere den Wert. Ein vorhandenes Objekt beweist nicht den richtigen Datensatz. Nenne Ursprung und bedeutungsgebende Prüfungen. Nutze erlaubte Daten und keine privaten Namen in öffentlichen Titeln.

Prüfe den Bericht lokal

Zwei benannte Schritte prüfen Anfang und Änderung. Ein kontrollierter Screenshot zeigt das lokale Ergebnis. Bestandene Schritte beweisen keine entfernte Persistenz. Der Film erklärt Berichtsstruktur, er zeigt keinen Kundenablauf.

Bei Fehlern hilft der Name, die Frage zu finden, ersetzt aber keine Details. Lies Assertion und Kontext. Nicht jede Aktion eines bestandenen Schritts wurde einzeln geprüft. Reine Klickschritte können ohne Ergebnisprüfung bestehen.

Prüfe Namen und Code gemeinsam

Kurze Regel: Titel nennt Frage, Körper enthält passende Aktion und Assertion, Umfang bleibt ehrlich. Aktualisiere Namen bei Änderungen. Ein veraltetes Label kann trotz korrekt engerem Code täuschen.

AnyTest beschreibt Erkundung und Tests zur Prüfung. Frage, ob Labels den erhobenen Belegen entsprechen. Kein besonderes AnyTest-Schrittformat wird behauptet. Namen erleichtern Lesen; Assertions tragen den Beweis.