Playwright

Par Thomas V-G le 13 octobre 2025
Lecture 9 minutes

Playwright, c’est quoi ?

Playwright est un framework développé par Microsoft. Il permet de lancer un navigateur et d’effectuer des actions comme le ferait un utilisateur réel, mais de manière scriptée et automatisée. Il réalise ce qu’on appelle des tests End-to-End (E2E).

On écrit souvent des tests unitaires et fonctionnels pour vérifier la partie back-end d’un projet. Après tout, on a généralement beaucoup plus de maîtrise sur le contexte et le fonctionnement du serveur d’un site que sur l’appareil de l’utilisateur.

Playwright permet de tester un site comme le ferait un utilisateur final, tout en variant les environnements en utilisant différents navigateurs et en adaptant les tailles d’écran.

Comment ça marche ?

On ne va pas s’attarder sur l’installation, qui se fait très facilement en suivant la documentation ici : https://playwright.dev/docs/intro

Remarque : ces tests ont été écrits en juillet 2025. Au moment où vous lisez cet article, le site v2.demo.sylius.com aura peut-être changé (structure du DOM, url, …). Ce qui pourra modifier le résultat des tests si vous les faites chez vous.

Premier test

Imaginons un test qui se rend sur le site de démonstration SyliusV2, clique sur un menu, accède à une fiche produit et l’ajoute au panier. On appellera le fichier ajoutAuPanier.spec.js

import { test } from '@playwright/test';

test.describe('Navigons sur le site', () => {

    test('Mon premier test', async ({ page }) => {

        // Allons sur la page d'accueil
        await page.goto('https://v2.demo.sylius.com/en_US/');

        // Cliquons sur le menu "Dresses" dans la navbar
        await page.locator('nav.navbar').getByText('Dresses').click();

        // Trouvons le deuxième produit et cliquons sur son lien
        const product = await page.locator('.products-grid > div').nth(2);
        await product.locator('a.link-reset').click();

        // Ajoutons le produit au panier
        await page.locator('#add-to-cart-button').click();

        // Attendons quelques secondes
        await page.waitForTimeout(3000);

        // Allons dans le panier
        await page.goto('https://v2.demo.sylius.com/en_US/cart/');

    });

});

On remarque qu’on accède à une variable page qui permet de faire beaucoup de choses :

  • Aller sur une URL avec goto()
  • Trouver un élément du DOM avec locator(), getByText()
  • Attendre avec waitForTimeout()
  • Mais il y a beaucoup d’autres fonctionnalités !

La syntaxe est très proche du JavaScript, avec des sélecteurs CSS. Un développeur front-end peut donc facilement prendre en main ce framework.

Lancement du test

Headless

On peut ensuite lancer son test avec la ligne de commande : npx playwright test

Un succès ressemblera à cela :

Une capture d'écran de 3 tests Playwright en succès

Une erreur, par exemple un ID incorrect pour un bouton d’ajout au panier, s’affichera de la manière suivante :

Capture d'écran de test Playwright avec une erreur. Le programme a stopé sans trouver le bouton identifié par #add-to-cart-buttonn

Le test essaye de trouver le trouver l’élément #add-to-cart-buttonn jusqu’à avoir une time out. Le sélecteur tente plusieurs fois jusqu’à une time out au cas où l’élément recherché serait ajouté dynamiquement dans la page après un certain temps.

Avec visualisation

Il est également possible d’ouvrir un client, qui montrera directement ce que le navigateur affiche grâce à la commande : npx playwright test –ui

Une capture d'écran de l'interface utilisateur Playwright à la fin d'un test

Le client contient différentes zones, notamment :

  • La liste des fichiers et des tests à gauche. Il est possible de tous les lancer en même temps, ou de n’en lancer qu’un seul si l’on souhaite se concentrer sur un scénario.
  • Les actions effectuées au milieu-gauche : toutes les commandes exécutées jusqu’à la fin du script ou une erreur.
  • Le rendu de l’écran du navigateur à droite (et la timeline en haut) pour voir le rendu, et les zones ciblées.
  • En bas, s’affichent différentes informations comme :

    • Le code source, les logs, annotations et pièces jointes du test
    • Les erreurs
    • Les rendus console et réseau du navigateur

En cas d’erreur, on aura un écran de ce type :

Une capture d'écran de l'interface utilisateur Playwright avec une erreur dans son test

 

 

 

 

 

 

 

 

 

On constate que les actions se sont arrêtées au clic sur le #add-to-cart-buttonn (car l’ID est erroné). L’onglet Errors en bas affiche la raison de l’échec.

Écriture automatique de tests

Nous avons vu plus haut comment étaient écrits les tests. Mais écrire manuellement peut être chronophage. Heureusement, il y a la possibilité de les écrire automatiquement avec cette commande : npx playwright codegen

Cela ouvrira :

  • Un navigateur
  • Un éditeur de texte
  • Une barre d’outils avec :

    • Bouton Enregistrer pour transcrire ses actions en code dans l’éditeur
    • Un outil de ciblage, pour récupérer un sélecteur d’élément
    • Des boutons qui écriront un test vérifiant la visibilité, le texte ou la valeur

Une capture d'écran de l'interface d'écriture de test automatique. Une fenêtre de navigateur et un éditeur de code

En cliquant sur Enregistrer (le rond rouge), toutes nos actions seront interprétées et transformées en code dans l’éditeur de texte.

Une capture d'écran de l'interface d'écriture de test automatique en cours d'écriture. Une fenêtre de navigateur et un éditeur de code où des commandes ont été écrites automatiquement

Il n’y a plus qu’à copier le texte, et le mettre dans un fichier de test.

Dans cet exemple, on obtient:

import { test, expect } from '@playwright/test';

test('test', async ({ page }) => {

    await page.goto('https://v2.demo.sylius.com/en_US/');

    await page.getByRole('link', { name: 'Glasses' }).click();

    await page.getByRole('button', { name: 'Sort: by position' }).click();

    await page.getByRole('link', { name: 'From A to Z' }).click();

    await page.getByRole('link', { name: 'Product Future Shield Glasses' }).click();

    await page.getByRole('button', { name: 'Add to cart' }).click();

    await page.getByLabel('cart button').click();

    await page.getByRole('link', { name: 'View and edit cart' }).click();

    await expect(page.locator('#sylius_shop_cart_items_0_quantity')).toHaveValue('1');

    await expect(page.getByRole('table')).toMatchAriaSnapshot(`- link "Future Shield Glasses"`);

});

Ce qui signifie :

  • On va sur le site
  • On clique sur un lien (ici “Glasses”)
  • On trie les produits dans l’ordre alphabétique
  • On clique sur le produit “Product Future Shield Glasses”
  • On l’ajoute au panier
  • On va dans le panier
  • On vérifie que le produit a une quantité de 1
  • On vérifie qu’un tableau contient un lien avec le texte “Future Shield Glasses”

L’écriture automatique de tests peut être pratique, mais a tout de même certaines faiblesses.

  • Elle ne gère pas le timing. Et s’il faut attendre la fin d’un chargement, le test peut échouer
  • Elle se base sur le texte des éléments. S’il y a plusieurs éléments qui correspondent, ou que le texte change, le test échouera.

Ça permet tout de même d’avoir une bonne base de script, à améliorer ou préciser manuellement par la suite.

Cas d’utilisation

Tester un scénario d’utilisation

La première fonction des tests End-to-End est de tester des scénarios d’utilisation. Comme dans l’exemple précédent on peut réaliser un parcours d’achat et voir si tout se passe correctement.

Faire des captures d’écran comparatives

Playwright permet aussi de faire des captures d’écran complètes ou partielles, et de les comparer à une ancienne capture. On peut s’en servir pour vérifier la non-régression de composants après un déploiement.

Par exemple, en changeant le menu “Dresses” par “Dress”, l’alignement on aura ces captures d’écran:

await expect(page.locator(‘.navbar’).first().toHaveScreenshot('navbar.png', { maxDiffPixels: 0 })

Avant

Une capture d'écran du menu principal de démo Sylius que le test s'attend à recevoir

Après

Une capture d'écran du menu principal de démo Sylius que le test reçoit dans la pratique

Diff

La différence entre la capture d'écran de menu attendue, et celle effectivement reçue. Les différences sont mises en valeur

 

On peut vite voir si l’affichage a évolué. On peut définir un minimum de différence en pixels pour ne pas relever des micro-changements.

Effectuer des tâches répétitives

Une autre tâche possible avec un outil de test End-to-End est de réaliser des tâches répétitives plusieurs fois. Ce n’est pas une des utilités vantées par l’éditeur. Mais si j’ai besoin de créer un grand nombre de commandes sur mon site sans le faire à la main, je peux faire un script qui le fera à ma place.

Problèmes possibles

Playwright est un outil pratique qui permet de tester son site de manière automatisée d’un point de vue utilisateur. Mais il faudra prendre en compte certaines contraintes :

  • Les composants dynamiques ou appels asynchrones en JavaScript sur le site vous demanderont d’ajouter un temps d’attente sur Playwright. Pour que le script attende la fin du chargement, vous devrez utiliser la fonction page.waitForTimeout(), ou gérer vos sélecteurs de manière à ce qu’ils vérifient que le chargement est fini.

  • Playwright navigue vraiment sur le site. Si vous testez le formulaire de contact, il sera vraiment soumis. Si vous voulez tester une commande, elle sera vraiment envoyée. S’il y a un reCAPTCHA, le robot sera intercepté. Il faudra soit avoir un moyen d’identifier les comportements de test et les ignorer, soit dire aux tests de s’arrêter juste avant le moment de l’envoi. De la même manière, les modales de cookies et autres popups s’afficheront. Il faudra donner l’instruction de les fermer pour que les tests fonctionnent.

  • Mettre à jour les tests en parallèle du site. Si le rédacteur ajoute du contenu sur une page, il faut que les tests continuent de fonctionner. L’idéal est de prévoir la possibilité d’évolution du contenu sans casser les codes. Ou bien, il faudra mettre à jour les tests manuellement.

Conclusion

Si vous voulez tester le fonctionnement du site en profondeur, Playwright et les tests End-to-End peuvent être une bonne solution pour vous.
On peut écrire tous types de comportements et les répéter. Si un bug est découvert, on peut faire évoluer les tests pour qu’ils vérifient les cas problématiques à l’avenir.
On peut aussi faire des captures d’écran pour voir directement à quoi ressemblent toutes les pages que l’on veut vérifier sans naviguer manuellement sur différents navigateurs et appareils.
Lancer des tests après un déploiement permet d’effectuer une recette automatique globale et d’alerter en cas de dysfonctionnement. Même si cela ne dispense pas d’une vérification manuelle.

Lancer des tests à la fin d’un développement permet de vérifier qu’il n’y a pas d’effet de bord et qu’on n’a rien oublié.

Site officiel : Playwright

Sur le même thème, découvrez nos autres articles
GIF