Attends le résultat, pas l'horloge

Un formulaire de paramètres s'enregistre lentement. Quelqu'un ajoute une pause de deux secondes avant de vérifier le message de réussite. Il passe sur leur ordinateur portable. La prochaine exécution de CI prend un peu plus de temps et échoue. Un autre développeur modifie la pause à cinq secondes. Le test est désormais plus lent, mais la raison pour laquelle il doit être effectué n'a toujours pas été expliquée.

La question utile n'est pas de savoir combien de secondes dormir. C'est ce qui prouve que la prochaine étape est prête. Ce guide construit une petite vérification des paramètres enregistrés autour de cette question, à l'aide de la documentation sur les assertions de Playwright et de son guide des meilleures pratiques. La capture d'écran est une démonstration locale illustrative, et non une application client ou une référence de produit.

Une pause devine. Une condition est vérifiée.

Dans la démo, cliquer sur Enregistrer modifie un élément d'état de Enregistré à Enregistré après un délai. Une requête de visibilité immédiate prend un instantané du présent. Il n'attend pas un état futur. Les assertions Web-first de Playwright vérifient à plusieurs reprises le localisateur jusqu'à ce que la condition attendue soit vérifiée ou que leur délai d'attente expire.

Comparez les deux approches dans un test où une page a déjà accédé à votre propre formulaire de paramètres de préparation :

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

Ce sont des extraits alternatifs, pas des instructions pour cliquer deux fois en un seul test. La deuxième assertion peut se terminer dès que Saved apparaît. Si elle n'apparaît jamais, l'assertion échoue au lieu d'attendre indéfiniment. Le délai d'expiration de l'assertion par défaut est de cinq secondes, selon la documentation actuelle sur l'assertion ; choisissez un délai d'attente local uniquement lorsque le comportement attendu de votre produit le justifie.

L'attente automatique n'est pas la même chose que l'attente du résultat

Playwright vérifie l'actionnabilité avant des actions telles qu'un clic. Un bouton peut devoir être visible, stable, activé et capable de recevoir des événements. Cela répond si le clic peut se produire. Cela ne prouve pas que la demande de sauvegarde est terminée ou que le serveur a conservé le nouveau paramètre.

Un statut de réussite peut constituer une condition raisonnable de préparation à la prochaine étape de l'assurance-chômage, mais il ne constitue pas une preuve indépendante de persévérance. Gardez ces tâches séparées : attendez Enregistré, rechargez la page des paramètres, puis vérifiez la valeur sélectionnée. Notre article précédent sur les résultats indépendants traite de cette limite de preuve ; ce guide se concentre sur le mécanisme de synchronisation qui vous permet d'effectuer le contrôle de manière fiable.

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

L'exemple suppose un champ accessible nommé Nom d'affichage et un enregistrement intermédiaire sécurisé pour le rechargement. Définissez ces contrats dans la démo ou dans votre application. Ne modifiez pas le profil d'un utilisateur en direct pour faciliter une expérience de chronométrage.

Lorsque l'attente échoue, ne le gonflez pas d'abord

Un délai d'attente d'assertion expiré est une preuve à inspecter. Le statut peut ne jamais être mis à jour. Le test peut cibler un ancien composant. La sauvegarde pourrait échouer. Ou bien le produit pourrait légitimement prendre plus de temps que prévu. Inspectez l'action et l'interface utilisateur qui en résulte avant de modifier un délai d'attente.

Le [guide d'actionnabilité] de Playwright (https://playwright.dev/docs/actionability) explique quelles actions attendent et quelles assertions sont réessayées. Les contrôles d'égalité génériques n'acquièrent pas ce comportement simplement parce qu'ils contiennent une valeur attendue. Préférez une assertion de localisateur pour une condition d'interface utilisateur changeante ; utilisez une assertion d'interrogation limitée lorsque la condition est en dehors de cette forme.

Évitez de transformer chaque échec en un délai d'attente partagé plus long. Un plafond plus long cache les symptômes et peut rendre une course interrompue beaucoup plus longue. Notez le signal de préparation prévu et à qui il appartient. Si aucun signal n'existe, un état de chargement ou un contrat de test plus clair peut être une meilleure solution qu'une autre mise en veille.

Une carte de révision pour les tests générés

Pour chaque étape sensible au timing, enregistrez l'action, l'état de préparation, le motif du délai d'attente et la vérification du résultat final. Dans notre démo : Enregistrer, le statut est égal à Enregistré, la fenêtre de réponse de sauvegarde convenue, puis le champ persiste après le rechargement. Cette petite carte est plus facile à consulter qu'une pile de pauses.

AnyTest décrit les agents explorant une application Web et créant des tests de bout en bout pour un examen humain. Si un flux généré semble trop rapide ou peu fiable, l'examinateur doit demander ce qui rend chaque transition prête. Il s'agit d'un principe de révision, et non d'une affirmation selon laquelle AnyTest expose les paramètres Playwright ou le code généré dans un format particulier.

Un seul ingénieur QA bénéficie lorsque les règles de synchronisation sont suffisamment explicites pour que les développeurs puissent les maintenir. Une équipe sans QA dédié peut utiliser la même carte lors de la révision du code. L'objectif est un test qui attend la bonne raison, échoue avec une limite utile et ne confond jamais une pause avec une preuve.