Avancez l'horloge, pas la durée d'exécution du test.

Un rappel apparaît après une longue période d'inactivité. Le test attend toute la période. Cela rend la suite coûteuse à exécuter, donc quelqu'un réduit le délai dans une version spéciale. Désormais, le test n'applique plus la même règle de timing. Le temps de navigation contrôlé offre une autre voie, à condition que le résultat soit nommé honnêtement.

Ce guide utilise la documentation de l'horloge de Playwright pour vérifier un petit rappel local. Son visuel est un compte à rebours inventé, pas une session de production ou un benchmark de performances. Nous contrôlons le temps côté navigateur pour exercer le comportement sélectionné. Nous ne prétendons pas que l'avancement de cette horloge modifie un serveur distant, fait expirer un jeton réel ou recrée toutes les conditions de planification.

Séparez l'horloge murale de la minuterie

Une application peut lire la date actuelle, planifier un délai d'attente ou mettre à jour selon un intervalle. Ces mécanismes sont liés, mais un test doit savoir lequel détermine le comportement. Une étiquette de date indiquant demain et un rappel qui se déclenche dans soixante secondes sont des contrats différents.

Le guide de l'horloge de Playwright décrit le contrôle des API d'heure, y compris la date et les minuteries. Sa méthode à heure fixe modifie l'heure signalée sans avancer les minuteries. L'installation de l'horloge offre une configuration contrôlée plus large. Choisissez la méthode à partir de la règle réelle de l'application, et non à partir de l'exemple le plus simple à coller.

Pour notre démo, la page planifie un rappel via setTimeout. Installez l'horloge contrôlée avant le démarrage du code de synchronisation de la page. Parcourez ensuite délibérément le calendrier de rappel :

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');

L'extrait utilise un appareil HTML local et une attente Playwright importée. Il s'agit d'un exemple de mécanisme et non d'une fonction de rappel complète. Le test devrait également vérifier ce qu'une personne peut faire après l'apparition du rappel et ce qui se passe lorsqu'elle le rejette. L'avancée du temps ne peut pas fournir ces décisions de produits.

Choisissez le comportement des rappels manqués

Le guide de l'horloge fait la distinction entre l'avancement des minuteries et le saut de temps. Lisez cette distinction avant de remplacer une longue attente. Un système qui se met à jour une fois par seconde peut se comporter différemment si chaque rappel planifié s'exécute par rapport à un saut qui simule le réveil d'un navigateur après une pause.

Utilisez runFor lorsque le scénario sélectionné nécessite d'avancer avec des rappels planifiés. Envisagez fastForward pour un scénario différent dans lequel le comportement de timing manqué est important, en suivant la sémantique documentée. Ne considérez pas les deux opérations comme interchangeables simplement parce que les deux arrivent à une date ultérieure. Le nom d'un test doit indiquer la situation qu'il représente.

Gardez un petit étui pour la limite juste avant le rappel et un autre pour le moment où elle doit apparaître. Pour un minuteur répétitif, ajoutez la règle de répétition uniquement si la fonctionnalité le promet. Une seule assertion finale peut manquer un rappel précoce ou plusieurs notifications en double.

L'heure du navigateur n'est pas l'horloge du serveur

Une session réelle peut expirer selon la politique du serveur. Déplacer l'horloge du navigateur ne modifie pas cette politique. Un compte à rebours de l'interface utilisateur peut indiquer qu'il a expiré alors que le serveur accepte toujours la demande, ou le serveur peut la rejeter avant que l'interface utilisateur ne le remarque. Ce sont différents éléments de preuve à tester séparément.

Pour une fonctionnalité authentifiée, déterminez si la source de vérité est une réponse du serveur, un horodatage d'expiration ou un minuteur local. Utilisez des entrées de préparation approuvées et des identités contrôlées. Ne modifiez jamais la session d'un compte réel ou l'horloge système d'une machine simplement pour faciliter une vérification de synchronisation illustrative.

Le fuseau horaire et les paramètres régionaux constituent une autre limite. Un test de minuterie ne valide pas automatiquement une date limite de calendrier autour des changements d'heure d'été ou de la date affichée dans chaque région. Ajoutez ces cas à partir de l'exigence réelle plutôt que d'élargir la signification d'un résultat vert.

Laissez un contrat de timing utile aux évaluateurs

Enregistrez la source de temps, le mécanisme installé, l'état initial, l'opération avancée et la limite attendue. Cette courte note permet à un coéquipier de comprendre pourquoi le test ne dort pas pendant une minute et quel comportement il protège toujours. Si le test échoue ultérieurement, vérifiez si l'application a déplacé le timing vers une autre couche avant d'augmenter les attentes arbitraires.

AnyTest décrit les agents explorant une application et créant des tests de bout en bout pour un examen humain. Utilisez le contrat de timing pour examiner tout voyage d'expiration proposé. Ce guide ne revendique pas de fonctionnalité de contrôle d'horloge AnyTest ni d'intégration de coureur. Des tests plus rapides sont utiles lorsque le raccourci préserve la question, et non lorsqu'il remplace silencieusement une horloge différente.