Stellen Sie die Uhr vor, nicht die Testlaufzeit.

Nach längerer Inaktivität erscheint eine Erinnerung. Der Test wartet den gesamten Zeitraum ab. Das macht den Betrieb der Suite teuer, sodass jemand die Verzögerung in einem speziellen Build reduziert. Jetzt wendet der Test nicht mehr dieselbe Zeitregel an. Eine kontrollierte Browserzeit bietet einen anderen Weg, sofern das Ergebnis ehrlich benannt wird.

In diesem Handbuch wird die Uhrdokumentation von Playwright verwendet, um eine kleine lokale Erinnerung zu überprüfen. Sein Bild ist ein erfundener Countdown, keine Produktionssitzung oder Leistungsbenchmark. Wir kontrollieren die browserseitige Zeit, um das ausgewählte Verhalten auszuüben. Wir behaupten nicht, dass das Vorrücken dieser Uhr einen Remote-Server verändert, ein echtes Token abläuft oder jede Planungsbedingung neu erstellt.

Trennen Sie die Wanduhr vom Timer

Eine Anwendung kann das aktuelle Datum lesen, eine Zeitüberschreitung planen oder in einem Intervall aktualisieren. Diese Mechanismen hängen zusammen, aber ein Test muss wissen, welcher Mechanismus das Verhalten auslöst. Ein Datumsetikett mit der Aufschrift „Morgen" und ein Rückruf, der in 60 Sekunden ausgelöst wird, sind unterschiedliche Verträge.

Der Uhrführer von Playwright beschreibt die Steuerung von Zeit-APIs, einschließlich Datum und Timer. Die Festzeitmethode ändert die gemeldete Zeit, ohne die Timer vorzustellen. Die Installation der Uhr ermöglicht eine umfassendere kontrollierte Einrichtung. Wählen Sie die Methode aus der tatsächlichen Regel der Anwendung und nicht aus dem Beispiel, das am einfachsten einzufügen ist.

Für unsere Demo plant die Seite eine Erinnerung über setTimeout. Installieren Sie die gesteuerte Uhr, bevor der Timing-Code der Seite startet. Gehen Sie dann den Rückrufplan gezielt durch:

await page.clock.install();
await page.setContent(`
  <p role="status">Waiting</p>
  <script>
    setTimeout(() => {
      document.querySelector('[role=status]').textContent = 'Reminder ready';
    }, 60000);
  </script>
`);
await page.clock.runFor(60000);
await expect(page.getByRole('status')).toHaveText('Reminder ready');

Das Snippet verwendet ein lokales HTML-Fixture und einen importierten Playwright-Expect. Es handelt sich um ein Beispiel eines Mechanismus, nicht um eine vollständige Erinnerungsfunktion. Der Test soll auch prüfen, was eine Person tun kann, nachdem die Erinnerung erscheint, und was passiert, wenn sie sie ablehnt. Die fortschreitende Zeit kann diese Produktentscheidungen nicht mehr herbeiführen.

Wählen Sie aus, wie sich verpasste Rückrufe verhalten

Der Uhrführer unterscheidet das Vorrücken durch Timer vom Zeitspringen. Lesen Sie diesen Unterschied, bevor Sie eine lange Wartezeit hinter sich lassen. Ein System, das einmal pro Sekunde aktualisiert, verhält sich möglicherweise anders, wenn jeder geplante Rückruf ausgeführt wird, als bei einem Sprung, der simuliert, dass der Browser nach einer Pause aufwacht.

Verwenden Sie runFor, wenn das ausgewählte Szenario eine Fortsetzung mit geplanten Rückrufen erfordert. Betrachten Sie fastForward für ein anderes Szenario, in dem verpasstes Timing-Verhalten von Bedeutung ist, und folgen Sie dabei der dokumentierten Semantik. Behandeln Sie die beiden Vorgänge nicht als austauschbar, nur weil beide einen späteren Zeitpunkt erreichen. Ein Testname sollte angeben, welche Situation er darstellt.

Behalten Sie ein kleines Feld für die Grenze direkt vor der Erinnerung und ein weiteres für den Punkt bei, an dem sie erscheinen soll. Fügen Sie für einen Wiederholungstimer die Wiederholungsregel nur hinzu, wenn die Funktion dies verspricht. Eine einzige abschließende Behauptung kann dazu führen, dass eine frühzeitige Erinnerung oder mehrere doppelte Benachrichtigungen übersehen werden.

Die Browserzeit ist nicht die Uhr des Servers

Eine echte Sitzung kann gemäß der Serverrichtlinie ablaufen. Durch das Verschieben der Browseruhr ändert sich diese Richtlinie nicht. Ein UI-Countdown kann als abgelaufen angezeigt werden, während der Server die Anfrage noch akzeptiert, oder der Server kann sie ablehnen, bevor die UI dies bemerkt. Dabei handelt es sich um verschiedene Beweisstücke, die separat geprüft werden müssen.

Stellen Sie für eine authentifizierte Funktion fest, ob die Quelle der Wahrheit eine Serverantwort, ein Ablaufzeitstempel oder ein lokaler Timer ist. Verwenden Sie genehmigte Staging-Eingaben und kontrollierte Identitäten. Ändern Sie niemals die Sitzung eines Live-Kontos oder die Systemuhr einer Maschine, nur um eine anschauliche Zeitüberprüfung zu erleichtern.

Zeitzone und Gebietsschema sind eine weitere Grenze. Ein Timer-Test validiert nicht automatisch eine Kalenderfrist im Hinblick auf die Sommerzeitumstellung oder das angezeigte Datum in jedem Gebietsschema. Fügen Sie diese Fälle aus der tatsächlichen Anforderung hinzu, anstatt die Bedeutung eines grünen Ergebnisses zu erweitern.

Hinterlassen Sie einen nützlichen Timing-Vertrag für Gutachter

Notieren Sie die Zeitquelle, den installierten Mechanismus, den Anfangszustand, den laufenden Betrieb und die erwartete Grenze. Diese kurze Notiz lässt einen Teamkollegen verstehen, warum der Test keine Minute lang schläft und welches Verhalten er dennoch schützt. Wenn der Test später fehlschlägt, prüfen Sie, ob die Anwendung das Timing auf eine andere Ebene verschoben hat, bevor Sie willkürliche Wartezeiten erhöhen.

AnyTest beschreibt Agenten, die eine Anwendung erkunden und End-to-End-Tests für die menschliche Überprüfung erstellen. Nutzen Sie den Timing-Vertrag, um jede geplante Ablaufreise zu prüfen. In diesem Handbuch wird weder eine AnyTest-Taktsteuerungsfunktion noch eine Runner-Integration behauptet. Schnellere Tests sind nützlich, wenn die Verknüpfung die Frage beibehält und nicht stillschweigend eine andere Uhr ersetzt.