Comment isoler les tests d’e-mails parallèles avec les verrous de test Playwright en 2026 ?

Un test reçoit le code de vérification d’un autre scénario, ou relit un ancien message dans la boîte partagée.

Action la plus rapide : utilisez un verrou nommé pour coordonner les tests qui accèdent à la même ressource, puis ajoutez un identifiant de test unique pour vérifier à quel scénario appartient chaque e-mail. Le verrou réduit les conflits d’accès ; il ne lie pas, à lui seul, un message à une exécution donnée.

Cet article s’adresse aux développeurs dont les tests Playwright s’exécutent en parallèle entre fichiers, processus de travail ou projets.
Il s’adresse aussi aux équipes QA qui valident des inscriptions, des codes de vérification et des notifications par e-mail.
Si vous maintenez l’environnement d’intégration continue, vous y trouverez des critères pour choisir entre verrou, compte distinct et boîte isolée.

Dernière vérification : 24 octobre 2026, à partir des notes de publication Playwright, du guide officiel sur les tests parallèles et de la référence de l’API Test. Les détails d’implémentation et la syntaxe à employer doivent être vérifiés pour la version réellement installée dans votre projet.

Avant de configurer : repérez ce qui est réellement partagé

Commencez par décrire le trajet d’un message dans votre test, de l’action qui le déclenche jusqu’à l’assertion qui le valide. Ne partez pas du principe que toute défaillance intermittente vient du parallélisme : le message peut aussi ne pas avoir été envoyé, être filtré, ou être retardé avant d’arriver dans la boîte de test. Votre objectif est d’abord de distinguer une compétition pour une ressource d’un défaut d’association entre message et scénario.

Inventoriez les éléments communs aux tests concernés :

• La boîte ou l’interface de lecture. Plusieurs scénarios interrogent-ils la même boîte, la même liste de messages ou le même point d’accès de lecture ?
• Le compte applicatif. Les tests réutilisent-ils un compte dont l’adresse, l’état d’inscription ou le code le plus récent change au fil des scénarios ?
• Les opérations d’envoi et de nettoyage. Un test supprime-t-il des messages, réinitialise-t-il un compte ou invalide-t-il un code pendant qu’un autre s’appuie sur le même état ?
• Les critères de sélection. Le test cherche-t-il un message à partir du destinataire et d’un identifiant précis, ou prend-il simplement le premier message correspondant à un sujet général ?

Ces vérifications séparent deux problèmes que l’on confond souvent. Le conflit d’accès se produit lorsque des tests manipulent au même moment un compte ou une boîte partagés. Le mauvais rattachement survient lorsque le test lit un message qui ne correspond pas à son scénario, même si les accès ont été coordonnés. Un verrou peut répondre au premier problème, pas automatiquement au second.

Notez aussi le périmètre exact de l’essai : test de votre propre produit ou environnement pour lequel vous avez une autorisation. L’objectif est de valider le flux d’inscription, de réinitialisation ou de notification de votre application, et non de créer des comptes en série sur un service tiers.

Au moment de choisir la configuration : nommez le verrou selon la ressource

Un nom de verrou doit représenter une ressource effectivement partagée, pas une catégorie vague comme « e-mails ». Si deux groupes de tests utilisent des comptes et des boîtes indépendants, leur faire partager le même verrou les ferait attendre inutilement. À l’inverse, donnez un nom commun aux scénarios qui peuvent entrer en concurrence pour le même compte ou la même boîte.

La décision porte donc sur le périmètre réel de l’exclusion :

La fonction des verrous de test et leur usage pour coordonner l’accès à des ressources partagées sont décrits dans le guide Playwright sur l’exécution parallèle. Mais ne déduisez pas de cette description que toutes les combinaisons de fichiers, de projets ou de processus sont couvertes de la même manière. Les portées disponibles, la syntaxe et les règles d’attente dépendent de l’API effectivement prise en charge par la version installée.

Avant d’écrire la configuration, confrontez donc trois éléments : la version dans le fichier de dépendances, la documentation officielle correspondante et l’endroit où le verrou est déclaré. Les références Test et TestInfo permettent de vérifier les API disponibles sans transposer à l’aveugle un exemple prévu pour une version différente.

Vous pouvez appliquer la même règle à un test isolé ou à un groupe describe, si la version et l’API retenues prennent en charge cette portée. Le principe n’est pas de verrouiller une suite entière par réflexe : déclarez ensemble les tests qui se disputent la même ressource et gardez séparés les parcours sans dépendance commune. Un verrou trop large peut masquer les effets du parallélisme et allonger la suite sans apporter de garantie supplémentaire sur l’identité des messages.

Enfin, ne confondez pas le verrou Playwright avec l’isolation offerte par le système de réception. Le verrou coordonne des tests qui déclarent le même verrou dans le périmètre qu’il prend en charge. Il ne crée pas une boîte indépendante, ne vide pas nécessairement les messages anciens et ne garantit pas que le service de réception ne présente qu’un seul e-mail.

Pendant l’exécution : rendez exclusifs les accès concurrents

Reliez maintenant le nom choisi aux tests qui touchent la ressource. Pour rendre la configuration auditable, consignez dans le code ou dans les commentaires le compte, la boîte ou l’opération protégée. Une personne qui lit la suite doit pouvoir comprendre pourquoi deux tests partagent un verrou, plutôt que supposer que son nom est un simple regroupement thématique.

Testez ensuite le comportement attendu dans un environnement maîtrisé :

• Les tests qui modifient le même compte déclarent le verrou associé à ce compte.
• Les tests qui lisent ou nettoient la même boîte déclarent le verrou correspondant lorsque ces opérations ne sont pas compatibles.
• Les scénarios qui utilisent leurs propres ressources ne récupèrent pas automatiquement le verrou commun.
• Les assertions continuent de vérifier le contenu et la provenance logique du message ; elles ne sont pas remplacées par l’attente du verrou.

Dans le guide officiel, Playwright décrit la coordination des tests qui accèdent à une ressource partagée afin d’éviter qu’ils s’exécutent en même temps. Cela ne signifie pas qu’une suite entière devient séquentielle. Un test qui ne dispute pas la même ressource peut rester parallèle, sous réserve de la configuration de votre projet. Vérifiez le comportement réel du mode d’exécution retenu, car le mode par défaut, la configuration parallèle et les groupes décrits comme séquentiels peuvent changer les tests qui se chevauchent.

Pour reproduire le conflit, commencez par deux scénarios de votre propre application qui écrivent dans le même état de compte ou lisent la même boîte. Faites-les tourner sans coordination et observez les traces. Ajoutez ensuite le verrou approprié et répétez la même expérience. Votre critère de réussite est limité : les opérations protégées ne se concurrencent plus selon la portée promise par l’API. Ce résultat ne prouve pas encore que la boîte ne contienne aucun ancien message ou que le code sélectionné appartienne à la bonne exécution.

Un test qui passe après l’ajout d’un verrou ne suffit pas à démontrer que le problème est résolu : gardez une assertion indépendante sur l’identité et le contenu du message.

Évitez aussi de présenter le verrou comme un outil de contrôle du service d’envoi. Il ne vérifie pas que le serveur applicatif a déclenché l’e-mail, que celui-ci a été accepté par le système de réception ou qu’il est arrivé dans le dossier attendu. Si votre question porte sur l’envoi ou la livraison, examinez ces étapes séparément. Le guide de diagnostic de la livraison des e-mails peut compléter le parcours quand le problème est l’absence ou le classement inattendu d’un message.

À réception du message : prouvez son association avec le scénario

Pour limiter les risques de codes de vérification reçus par le mauvais scénario, utilisez un identifiant distinctif associé à chaque exécution du test. Votre application de test peut faire figurer cet identifiant dans un champ exploitable par votre système de lecture, dans le contenu du message ou dans les données de test du destinataire, selon ce que votre produit sait réellement émettre. Le point important est que le test puisse retrouver le message à partir d’un critère propre au scénario, et non seulement de son sujet ou de sa date d’arrivée.

Une vérification robuste suit une chaîne cohérente :

• Le scénario génère ou reçoit un identifiant propre à son exécution.
• Cet identifiant est transmis au flux de votre application qui provoque l’envoi.
• Le test cherche un message dont les données observables correspondent à cet identifiant.
• Il extrait le code ou le lien et vérifie qu’il correspond à l’état de ce même scénario.
• Il enregistre un échec explicite si aucun message correspondant n’est trouvé, plutôt que de choisir silencieusement un autre message.

Pour une nouvelle tentative après échec, distinguez également l’exécution précédente de la tentative courante. Si la boîte reste partagée, un message valide lors du premier passage peut ne plus l’être pour le suivant. Votre assertion doit établir le rattachement attendu au lieu de faire confiance au message le plus récent. Une manière utile de raisonner consiste à considérer le destinataire, l’identifiant de scénario et l’état applicatif comme des éléments complémentaires ; si l’un est absent, déterminez ce qui prouve encore la provenance du message.

Cette discipline aide à distinguer une erreur de test d’un défaut produit. Si le message porte le bon identifiant, mais que le lien ou le code ne fonctionne pas, le problème est probablement ailleurs que dans le choix de la boîte. Si aucun message ne porte l’identifiant attendu, le test doit conserver assez de traces pour que vous puissiez vérifier si l’envoi a été déclenché et si la lecture a cherché le bon élément.

En cas de nouvelle tentative : vérifiez l’état conservé et le nettoyage

Un verrou coordonne l’accès aux ressources, mais la stratégie de nouvelle tentative et les opérations de nettoyage restent à examiner. La documentation Playwright sur les nouvelles tentatives décrit le comportement de reprise des tests. Dans votre projet, vérifiez comment ce comportement interagit avec les comptes, les messages et les données déjà créées ; ne supposez pas qu’une reprise repart automatiquement d’un état vierge.

Pour chaque étape de reprise, répondez à ces questions dans vos tests et vos traces :

• Le compte est-il réinitialisé avant la nouvelle tentative, ou son état précédent demeure-t-il ?
• Le message précédent est-il encore lisible dans la boîte ?
• Le nettoyage est-il effectué par le scénario qui détient la ressource, ou par une étape indépendante susceptible d’intervenir pendant un autre test ?
• L’identifiant de la tentative actuelle permet-il de différencier le nouveau message de l’ancien ?
• Les journaux montrent-ils quel message a été sélectionné et quelle assertion a échoué ?

Ne supprimez pas tous les messages d’une boîte commune comme raccourci si d’autres tests peuvent l’utiliser au même moment. Dans ce cas, le nettoyage lui-même constitue un accès concurrent à la ressource : il doit être inclus dans le périmètre coordonné, ou remplacé par un mécanisme ciblé qui ne touche que les données du scénario concerné. Le choix dépend des capacités réelles de votre système de test ; ne promettez pas une isolation que votre interface de réception ne fournit pas.

Pour éviter que les journaux ne brouillent une enquête, consignez des informations utiles à l’analyse : identifiant de scénario, étape de reprise, critère de recherche du message et résultat de l’assertion. Évitez d’y recopier des données personnelles réelles ou le contenu complet de messages sans nécessité. Une procédure de gestion des données de test doit aussi préciser ce qui est créé, conservé et supprimé dans votre environnement.

Après validation : décidez si le verrou suffit

Utilisez les conditions suivantes pour choisir la suite. Elles évitent de conserver un verrou par habitude alors que le défaut vient d’un message ancien, ou de réorganiser toute l’infrastructure pour un conflit que la coordination résout.

• Si les échecs apparaissent uniquement lorsque plusieurs tests touchent simultanément le même compte ou la même boîte, alors conservez le verrou, limitez-le aux tests concernés et documentez la ressource protégée.
• Si les tests restent susceptibles de lire un message ancien ou destiné à un autre scénario, alors ajoutez un identifiant de corrélation et une assertion explicite, même si le verrou est conservé.
• Si les comptes modifient des états incompatibles ou si l’historique d’une boîte rend l’association incertaine, alors passez à des comptes ou à des cibles de réception distincts lorsque votre environnement le permet.
• Si le test doit vérifier une vraie arrivée de message et que votre boîte de test ne permet pas d’établir son identité ou son état de conservation, alors choisissez un mode de réception adapté avant de conclure que le verrou garantit l’acceptation de bout en bout.

Le bon résultat d’une suite de tests n’est pas seulement l’absence d’échecs intermittents. Vous devez pouvoir expliquer quelle ressource est coordonnée, quel message a été sélectionné et pourquoi il appartient au scénario en cours. Le verrou peut apporter une partie de cette garantie ; il ne remplace ni l’assertion de provenance ni l’acceptation réelle du message dans votre environnement.

Pour préparer la validation des étapes et des données, la liste de contrôle des e-mails pour l’assurance qualité peut compléter votre procédure. Si vous n’avez pas encore décidé quel type de réception convient à votre scénario, consultez également le guide des adresses e-mail jetables en tenant compte de la nécessité éventuelle de recevoir des messages plus tard ou d’y répondre.

FAQ : portée des verrous et choix de réception

Un verrou nommé coordonne-t-il automatiquement plusieurs projets ou exécutions ?

Ne le présumez pas. La portée dépend de l’API et de la version de Playwright utilisées, ainsi que du périmètre où les tests déclarent le verrou. Vérifiez la documentation correspondant à votre installation et testez le cas réel entre fichiers ou projets. Ne supposez pas qu’un même nom coordonne des exécutions séparées ou différents environnements sans confirmation officielle.

Comment savoir si le verrou est la bonne correction ?

Comparez le comportement des mêmes scénarios avec et sans coordination, puis examinez si les défaillances observées concernent une ressource effectivement partagée. Si le conflit disparaît mais que des messages anciens restent sélectionnables, le verrou ne répond qu’à une partie du problème. Ajoutez alors une association vérifiable entre le scénario et le message au lieu d’élargir le verrou sans diagnostic.

Quelles informations doivent permettre de reconnaître le message du test en cours ?

Privilégiez un identifiant généré pour le scénario et vérifiable dans le message ou dans les données de réception disponibles. Contrôlez ensuite que le code ou le lien extrait correspond à l’état courant du compte. La date d’arrivée seule, l’ordre dans la boîte ou le sujet générique ne constituent pas une preuve suffisante quand plusieurs scénarios et nouvelles tentatives partagent la réception.

Quand une boîte indépendante apporte-t-elle plus qu’un verrou ?

Une boîte ou une cible de réception distincte devient préférable lorsque le contenu partagé ne peut pas être filtré de façon fiable, que les tests nettoient des données dont d’autres ont besoin, ou que des états de compte incompatibles s’entremêlent. Le verrou reste utile pour les conflits d’accès, mais il ne crée pas une séparation des données. Évaluez les capacités et la conservation réelles avant de changer votre architecture de test.

Si votre scénario QA doit effectivement recevoir un e-mail de votre propre produit, vous pouvez aussi examiner MaskSend comme option de réception temporaire : le service est accessible sans inscription et permet de commencer sans exposer votre boîte principale. Vérifiez d’abord sur la page du service que les fonctions disponibles et la conservation des messages répondent à vos assertions et à vos reprises ; un outil de réception ne remplace ni l’identifiant de test ni le contrôle de provenance.

Questions fréquentes