Warten Sie auf das Ergebnis, nicht auf die Uhr

Ein Einstellungsformular wird langsam gespeichert. Jemand fügt eine zwei Sekunden lange Pause ein, bevor er die Erfolgsmeldung überprüft. Es gibt ihren Laptop weiter. Der nächste CI-Lauf dauert etwas länger und schlägt fehl. Ein anderer Entwickler ändert die Pause auf fünf Sekunden. Der Test ist jetzt langsamer, aber der Grund, warum er fortgesetzt werden sollte, fehlt noch.

Die nützliche Frage ist nicht, wie viele Sekunden man schlafen soll. Die Beweise besagen, dass der nächste Schritt bereit ist. In diesem Leitfaden wird eine kleine Überprüfung gespeicherter Einstellungen rund um diese Frage erstellt, wobei die Behauptungsdokumentation von Playwright und der Best-Practice-Leitfaden verwendet werden. Der Screenshot ist eine veranschaulichende lokale Demo, keine Kundenanwendung oder ein Produkt-Benchmark.

Eine Pause vermutet. Eine Bedingung prüft.

Wenn Sie in der Demo auf „Speichern" klicken, ändert sich nach einer Verzögerung ein Statuselement von „Speichern" in „Gespeichert". Eine sofortige Sichtbarkeitsabfrage erstellt eine Momentaufnahme der Gegenwart. Es wartet nicht auf einen zukünftigen Zustand. Die Web-First-Assertions von Playwright überprüfen den Locator wiederholt, bis die erwartete Bedingung erfüllt ist oder ihr Timeout abläuft.

Vergleichen Sie die beiden Ansätze in einem Test, bei dem eine Seite bereits zu Ihrem eigenen Staging-Einstellungsformular navigiert ist:

// A fixed delay does not express the requirement.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await page.waitForTimeout(2000);
expect(await page.getByRole('status').innerText()).toBe('Saved');

// The expected state controls when the check finishes.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await expect(page.getByRole('status')).toHaveText('Saved');

Dabei handelt es sich um alternative Snippets, nicht um Anweisungen, in einem Test zweimal zu klicken. Die zweite Behauptung kann beendet werden, sobald „Gespeichert" angezeigt wird. Wenn es nie erscheint, schlägt die Behauptung fehl, anstatt auf unbestimmte Zeit zu warten. Das Standard-Assertion-Timeout beträgt gemäß der aktuellen Assertionsdokumentation fünf Sekunden. Wählen Sie ein lokales Timeout nur dann aus, wenn das erwartete Verhalten Ihres Produkts dies rechtfertigt.

Automatisches Warten ist nicht dasselbe wie Ergebniswarten

Playwright prüft die Umsetzbarkeit vor Aktionen wie einem Klick. Eine Schaltfläche muss möglicherweise sichtbar, stabil, aktiviert und in der Lage sein, Ereignisse zu empfangen. Das beantwortet die Frage, ob der Klick stattfinden kann. Dies beweist nicht, dass die Speicheranforderung abgeschlossen wurde oder dass der Server die neue Einstellung beibehalten hat.

Ein Erfolgsstatus kann eine angemessene Bereitschaftsbedingung für den nächsten UI-Schritt sein, ist jedoch kein unabhängiger Beweis für die Beständigkeit. Halten Sie diese Jobs getrennt: Warten Sie auf „Gespeichert", laden Sie die Einstellungsseite neu und überprüfen Sie dann den ausgewählten Wert. In unserem früheren Artikel über unabhängige Ergebnisse wird diese Beweisgrenze erörtert. Dieser Leitfaden konzentriert sich auf den Synchronisierungsmechanismus, der Sie zuverlässig zur Prüfung führt.

await expect(page.getByRole('status')).toHaveText('Saved');
await page.reload();
await expect(page.getByLabel('Display name')).toHaveValue('Demo user');

Das Beispiel setzt ein zugängliches Feld mit dem Namen „Anzeigename" und einen nachladesicheren Staging-Datensatz voraus. Definieren Sie diese Verträge in der Demo oder Ihrer App. Ändern Sie nicht das Profil eines Live-Benutzers, um ein Timing-Experiment bequemer zu gestalten.

Wenn das Warten fehlschlägt, blasen Sie es nicht zuerst auf

Ein abgelaufenes Assertion-Timeout ist ein zu prüfender Beweis. Der Status wird möglicherweise nie aktualisiert. Der Test zielt möglicherweise auf eine alte Komponente ab. Das Speichern schlägt möglicherweise fehl. Oder das Produkt braucht möglicherweise länger als derzeit erwartet. Überprüfen Sie die Aktion und die resultierende Benutzeroberfläche, bevor Sie ein Zeitlimit ändern.

Der Umsetzungsleitfaden von Playwright erklärt, welche Aktionen warten und welche Behauptungen erneut ausgeführt werden. Generische Gleichheitsprüfungen erfassen dieses Verhalten nicht einfach deshalb, weil in ihnen ein erwarteter Wert enthalten ist. Bevorzugen Sie eine Locator-Behauptung für eine sich ändernde UI-Bedingung; Verwenden Sie eine begrenzte Abfrageaussage, wenn die Bedingung außerhalb dieser Form liegt.

Vermeiden Sie es, jeden Fehler in eine größere gemeinsame Zeitüberschreitung umzuwandeln. Eine längere Obergrenze verbirgt die Symptome und kann dazu führen, dass ein unterbrochener Lauf viel länger dauert. Notieren Sie das beabsichtigte Bereitschaftssignal und wem es gehört. Wenn kein Signal vorhanden ist, kann ein klarerer Ladezustand oder ein Testvertrag eine bessere Lösung sein als ein weiterer Ruhezustand.

Eine Überprüfungskarte für generierte Tests

Notieren Sie für jeden zeitkritischen Schritt die Aktion, den Bereitschaftszustand, den Grund für die Zeitüberschreitung und die endgültige Ergebnisprüfung. In unserer Demo: Speichern, Status gleich Gespeichert, das vereinbarte Speicherantwortfenster, dann bleibt das Feld nach dem erneuten Laden bestehen. Diese kleine Karte ist leichter zu lesen als ein Haufen Pausen.

AnyTest beschreibt Agenten, die eine Web-App erkunden und End-to-End-Tests zur menschlichen Überprüfung erstellen. Wenn ein generierter Fluss zu schnell oder unzuverlässig erscheint, sollte der Prüfer fragen, was jeden Übergang bereit macht. Hierbei handelt es sich um einen Überprüfungsgrundsatz und nicht um den Anspruch, dass AnyTest Playwright-Einstellungen oder generierten Code in einem bestimmten Format offenlegt.

Ein einzelner QA-Ingenieur profitiert davon, wenn die Synchronisierungsregeln explizit genug sind, damit Entwickler sie verwalten können. Ein Team ohne dedizierten QA kann während der Codeüberprüfung dieselbe Karte verwenden. Das Ziel ist ein Test, der auf den richtigen Grund wartet, mit einer nützlichen Grenze fehlschlägt und eine Pause niemals als Beweis verwechselt.