Un test Playwright échoue seulement en environnement de préproduction

Error: expect(locator).toBeVisible() failed — Timeout 5000ms exceeded. Ce message apparaît uniquement sur l’environnement de préproduction, jamais en local, alors que le code testé n’a pas changé entre les deux. La tentation immédiate est d’augmenter le délai d’attente dans le test. C’est rarement la bonne réponse : un test qui échoue dans un seul environnement pointe presque toujours vers une différence de configuration ou de données, pas vers une lenteur générique du réseau.

Ce cas s’inspire d’une extension de réservation d’ateliers testée avec Playwright, où le parcours de confirmation échouait systématiquement en préproduction sans qu’aucune erreur ne remonte en local.

Symptôme

Le test vérifie qu’après soumission d’un formulaire de réservation, un message de confirmation apparaît dans un délai raisonnable. En local, ce message apparaît en quelques centaines de millisecondes. En préproduction, le sélecteur reste introuvable jusqu’à l’expiration du délai d’attente, et le test échoue avec un timeout, sans message d’erreur applicatif visible dans la capture d’écran jointe au rapport.

Diagnostic

Trois pistes ont été vérifiées dans l’ordre, chacune plus coûteuse à explorer que la précédente :

1. Les données de préproduction diffèrent des données locales. Le formulaire teste la disponibilité d’un atelier précis par son identifiant. En préproduction, cet identifiant correspondait à un atelier archivé, ce qui déclenchait un message d’indisponibilité au lieu du message de confirmation attendu — un problème de fixture, pas de code.
2. La configuration réseau bloque un appel tiers. Une fois l’identifiant corrigé, le test échouait encore : la trace Playwright (activée via trace: 'on-first-retry' dans la configuration) montrait un appel vers un service de vérification d’adresse resté bloqué en attente, ce service n’étant accessible qu’en production sur cet environnement précis.
3. Un en-tête d’authentification de préproduction interfère. L’environnement de préproduction protège l’accès par une authentification HTTP basique au niveau du serveur web, ajoutée après le déploiement initial du site, sans être reproduite dans la configuration Playwright utilisée par la CI.

Isoler la cause avec les outils Playwright

Le débogage a démarré par l’activation systématique de la trace et des captures d’écran sur échec, deux réglages du fichier de configuration :

// playwright.config.ts
export default {
  use: {
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
};

La trace enregistre chaque requête réseau, chaque action du navigateur et l’état du DOM à chaque étape, ce qui permet de rejouer précisément le scénario après coup dans le visualiseur de traces Playwright, sans devoir reproduire l’échec en direct sur l’environnement concerné.

Correctif

La correction ne portait sur aucune ligne du test lui-même : le problème venait de l’environnement. Trois actions ont résolu le cas :

• Remplacement de l’identifiant d’atelier codé en dur par une création de fixture dédiée avant chaque exécution, disponible identiquement dans tous les environnements.
• Ajout d’un mock ou d’une désactivation du service de vérification d’adresse en environnement de test, pour ne plus dépendre d’un appel externe indisponible en préproduction.
• Transmission des identifiants d’authentification HTTP basique à Playwright via l’option httpCredentials de la configuration, propre à l’environnement de préproduction.

Prévention

Pour éviter que ce type d’écart ne se reproduise avec une autre extension du même projet, deux pratiques ont été adoptées : générer les données de test par une fixture reproductible plutôt que de coder en dur un identifiant existant, et documenter dans un fichier dédié chaque différence de configuration attendue entre les environnements (authentification, domaines autorisés, services externes désactivés), consultée systématiquement à chaque nouveau test ajouté à la suite.

Notre verdict

Un test qui échoue uniquement sur un environnement donné mérite d’être traité comme un signal de configuration avant d’être traité comme un bug de test. Augmenter un délai d’attente masque le symptôme sans corriger la cause ; activer la trace Playwright dès le premier échec fait gagner l’essentiel du temps de diagnostic, en révélant en quelques minutes ce qui aurait pu prendre une matinée entière à reproduire manuellement.