Playwright contrôle les navigateurs et teste les applications web. Dans l’écosystème JavaScript et TypeScript, Playwright Test fournit un exécuteur, des fixtures, des assertions, des projets et des rapports. Les testeurs disposent de commandes pratiques, d’une isolation des états et d’un historique détaillé des échecs.
L’outil convient aux parcours utilisateur, aux états d’interface et à certaines tâches API. L’attente automatique ne remplace pas la compréhension de l’application : un bouton utilisable ne signifie pas que le processus métier est terminé, et une réponse HTTP réussie ne garantit pas des données correctes.
Installation et reproductibilité
Pour un nouveau projet pédagogique, utilisez npm init playwright@latest. Choisissez JavaScript ou TypeScript et l’installation des navigateurs. Utilisez une version de Node compatible avec la version retenue. Dans un dépôt existant, conservez package-lock.json et installez les dépendances avec npm ci.
Les versions des navigateurs dépendent de la version installée de Playwright. Après une mise à jour du paquet, mettez à jour les navigateurs et vérifiez les dépendances système de la CI. Un exécutable global arbitraire peut créer des écarts entre postes locaux et agents ; documentez explicitement ce choix.
Locators et noms accessibles
Playwright propose des locators par rôle, libellé, texte et identifiant de test. Un locator décrit comment trouver un élément dans l’état courant de la page. Cela évite de conserver une ancienne référence DOM que l’application peut remplacer au rendu.
Choisissez les attributs selon leur sens. Pour un formulaire, getByLabel relie le test au libellé accessible ; pour un bouton, getByRole avec un nom exprime l’action utilisateur. Si plusieurs éléments correspondent, précisez le conteneur. Prendre automatiquement le premier peut masquer une ambiguïté et déclencher le mauvais bouton.
Un exemple autonome
Dans le projet créé, enregistrez tests/profile.spec.js. L’exemple utilise une page en mémoire sans serveur. Exécutez npx playwright test tests/profile.spec.js. La règle pédagogique refuse un nom vide et affiche un succès pour un nom non vide ; aucune donnée n’est réellement persistée.
const { test, expect } = require('@playwright/test');
test('validates the name after submission', async ({ page }) => {
await page.setContent(`
<label>Name <input id="name"></label>
<button id="save">Save</button><p role="status"></p>
<script>
document.querySelector('#save').onclick = () => {
const name = document.querySelector('#name').value.trim();
setTimeout(() => {
document.querySelector('[role=status]').textContent =
name ? 'Saved' : 'Enter a name';
}, 100);
};
</script>`);
await page.getByRole('button', { name: 'Save' }).click();
await expect(page.getByRole('status')).toHaveText('Enter a name');
await page.getByLabel('Name').fill('Anna');
await page.getByRole('button', { name: 'Save' }).click();
await expect(page.getByRole('status')).toHaveText('Saved');
});Attendez une erreur pour la valeur vide, puis un succès pour une valeur valide. toHaveText répète l’observation jusqu’à satisfaction de la condition ou expiration du délai. Les actions et assertions asynchrones nécessitent await ; l’omettre peut perturber l’ordre et laisser des vérifications inachevées.
Ce que l’outil attend réellement
Avant une action, Playwright vérifie les conditions nécessaires, comme la visibilité et la possibilité d’interagir, selon l’opération. Il ignore si un calcul en arrière-plan, un envoi d’e-mail ou le traitement d’une file est terminé. Ces résultats exigent une condition observable distincte.
Préférez les assertions adaptées au web dynamique. Lire immédiatement un texte puis le comparer avec une assertion simple ne vérifie qu’un instant. N’allongez pas non plus tous les délais démesurément : attendre davantage ne corrige pas un scénario où l’événement ne doit pas se produire.
Passer à un vrai profil
Créez un utilisateur de test distinct, ouvrez son espace personnel et envoyez un nom composé uniquement d’espaces. Attendez une erreur et la conservation de la valeur enregistrée. Dans un autre scénario, envoyez un nouveau nom valide, puis relisez le profil via l’UI ou l’API selon l’objectif du test.
Un test simulant le réseau vérifie le traitement client de la réponse fournie. Gardez un test d’intégration distinct, sans remplacer cette opération, pour vérifier la persistance réelle. Le nom de la suite doit distinguer clairement une erreur UI contrôlée d’une vraie connexion au backend.
Fixtures et indépendance
Playwright Test utilise des contextes pour isoler l’état du navigateur entre tests. Cela aide pour les cookies et le stockage, mais n’isole pas automatiquement les enregistrements serveur. Deux contextes partageant un compte peuvent encore modifier le même profil ou panier.
Les fixtures peuvent préparer les utilisateurs, clients API et entités nécessaires. Choisissez volontairement leur portée. Une ressource partagée au niveau d’un worker doit être sûre pour tous ses tests ; mieux vaut créer séparément les données modifiables de chaque scénario.
Projets et matrice de navigateurs
Les projets décrivent des configurations : navigateur, dimensions, langue et autres paramètres. Exécutez une matrice fondée sur les risques plutôt que toutes les combinaisons possibles. Validez d’abord le parcours critique, puis ajoutez les zones sensibles à l’environnement retenu.
L’émulation mobile ne remplace pas un vrai téléphone, son clavier, ses permissions et ses intégrations système. Tester WebKit automatiquement ne constitue pas non plus une validation complète du Safari des utilisateurs. Consignez les limites de couverture avec les résultats.
Traces et analyse
Trace Viewer permet d’examiner les actions et l’état de la page autour d’un échec. Enregistrez les traces selon une politique convenue, par exemple lors d’une nouvelle tentative ou d’un échec, et rendez-les accessibles depuis la CI. Avant publication, examinez les données présentes dans les traces réseau et les captures.
Partez de la première attente non satisfaite : quelle requête a été envoyée, quelle réponse est revenue et qu’a affiché l’UI ? Ne réécrivez pas aveuglément un locator si le backend est indisponible. Une nouvelle exécution réussie est une observation utile, mais le premier échec doit encore être classé.
Pour un scénario multiutilisateur, créez deux contextes distincts et précisez le rôle de chaque participant dans le rapport. Un fichier d’état de stockage accélérant la connexion ne doit ni mélanger les comptes ni exposer des sessions dans un artefact public. Vérifiez son environnement et sa validité. Si la préparation de l’authentification échoue, identifiez cette étape : des dizaines d’erreurs ultérieures sur les éléments de l’espace personnel ne sont pas des défauts d’interface indépendants.
Erreurs et conclusions pratiques
Les problèmes fréquents sont l’absence d’await, des comptes modifiables partagés, des clics forcés sans analyse et la vérification d’un simple message. Relisez les tests générés : les générateurs aident à démarrer, mais ne choisissent ni les risques, ni les données, ni les critères de réussite.
Une suite Playwright fiable combine isolation, locators clairs, résultats métier explicites et artefacts utiles. Le démarrage rapide de l’outil est précieux si l’équipe maîtrise aussi soigneusement l’état serveur et les limites de couverture.
Lectures complémentaires
- →Playwright : installation
- →Playwright : attente automatique
- →Playwright : fixtures de test
- →Playwright : visualiseur de traces
Un exercice local reproductible
Le projet de pratique fixe @playwright/test 1.59.1 avec un fichier de verrouillage et utilise un environnement local Python. Ses sept cas Chromium testent le formulaire de pseudonyme avec des entrées vides, courtes, aux limites, trop longues, contenant des espaces ou de l’Unicode. Chaque cas possède sa propre page et déclare le résultat attendu. Aucun compte externe ni site de production n’intervient.
npm ci
npx playwright install chromium
npm test
# If a test fails and produces a trace:
npx playwright show-trace test-results/<case-directory>/trace.zipLa configuration démarre le serveur local et conserve les traces en cas d’échec. Les locators utilisent le libellé du champ et le rôle du bouton pour exprimer l’intention utilisateur. Les assertions réessaient jusqu’à satisfaction de leur condition ou expiration ; des pauses arbitraires sont inutiles pour ce formulaire synchrone.
await page.goto("/demo.html");
await page.getByLabel("Nickname").fill("ab");
await page.getByRole("button", { name: "Validate" }).click();
await expect(page.getByRole("alert")).toHaveText("Use 3–12 ASCII letters.");
await expect(page.getByLabel("Nickname")).toBeFocused();Pour provoquer volontairement un échec, changez le texte d’erreur attendu dans un test local, exécutez ce test seul, inspectez la trace conservée, puis restaurez l’assertion. Un test réussi prouve que cet exemple satisfait ces vérifications, pas qu’un vrai produit est accessible ou entièrement testé. Ajoutez le vrai parcours et les assertions backend lors de l’adaptation.
Pour aller plus loin
Télécharger le laboratoire local de pratique (ZIP)
Analyser les tests intermittents