Apprendre Playwright quand on vient de Selenium

Tu connais déjà le test : tu as lu des cas, écrit des scénarios, analysé des échecs. Tu ouvres la documentation de Playwright, tu lances un premier scénario, et tu te surprends à l'écrire avec les réflexes d'un autre outil ou d'un autre métier. C'est le point de départ de la plupart de ceux qui s'y mettent, et c'est là que les semaines se perdent.

Cet article propose trois parcours, selon d'où tu viens : Selenium, le test manuel ou le développement. Pour chacun, tu verras ce que tu peux garder, ce qu'il faut désapprendre et par quoi commencer. Je termine sur la façon de choisir entre apprendre seul et te faire accompagner.

Partenariat commercial : dans cet article, je présente la formation Mission Playwright de Matthieu Bridoux, avec qui je suis partenaire.

Trois choses qui changent, quel que soit ton point de départ

Avant les parcours, trois différences que tu rencontreras de toute façon, parce qu'elles tiennent à la façon dont Playwright est construit.

Il attend à ta place. Avant une action comme un clic, Playwright vérifie que le locator désigne un seul élément, que celui-ci est visible, stable (il ne bouge plus), activé et qu'il reçoit bien les événements, donc qu'aucun autre élément ne le recouvre. Si ces conditions ne sont pas réunies dans le délai imparti, l'action échoue avec une TimeoutError (documentation sur l'actionnabilité).

Chaque test a son propre contexte. Playwright crée un contexte de navigateur pour chaque test. Chaque test dispose donc de son propre localStorage, de son propre sessionStorage et de ses propres cookies, et la documentation précise que ces contextes sont rapides et peu coûteux à créer (documentation sur les contextes).

Les locators suivent ce que l'utilisateur perçoit. La documentation recommande de privilégier les locators par rôle, comme getByRole('button', { name: 'Payer' }), plutôt qu'un sélecteur accroché à la structure de la page.

Selon ton parcours, ces trois points ne te heurtent pas au même endroit. C'est ce qui justifie de les traiter séparément.

Parcours 1 : tu viens de Selenium

Tu as un avantage réel : tu sais déjà lire le DOM, choisir un locator, gérer des données de test et comprendre pourquoi un test automatisé casse. Rien de tout cela n'est à refaire. Ton problème est l'inverse : tes habitudes sont solides, et certaines n'ont plus lieu d'être.

Ce que tu gardes. Ta lecture d'un échec, ta méthode pour choisir les parcours à automatiser, ton expérience des données et de l'intégration continue. Le principe du Page Object te reste aussi utile : la documentation de Playwright propose elle-même des objets de page, associés à des fixtures.

Ce que tu désapprends, trois réflexes en particulier.

1. Poser une attente avant chaque action. Avec Selenium, tu as l'habitude d'attendre explicitement qu'un élément soit cliquable. Avec Playwright, l'attente fait partie de l'action.

# Selenium : attente explicite, puis clic
WebDriverWait(driver, 10).until(
    EC.element_to_be_clickable((By.CSS_SELECTOR, "button.checkout"))
).click()

// Playwright : l'action vérifie elle-même que le bouton est prêt
await page.getByRole('button', { name: 'Payer' }).click();

1. Recréer tes utilitaires maison. Si ta boîte à outils Selenium contient une fonction clickWhenReady ou un waitForPageLoad, regarde d'abord ce que Playwright fait déjà avant de la réécrire. Chaque utilitaire en moins est du code que personne n'aura à maintenir.
2. Partager un navigateur et un état entre les tests. Avec Playwright, chaque test part d'un contexte neuf. Pour ne pas te reconnecter à chaque test, la documentation propose un projet setup qui se connecte une fois et enregistre l'état d'authentification dans un fichier, que les tests rechargent ensuite avec storageState. Elle précise de ne pas versionner ce fichier, car il contient des cookies sensibles, et de ne pas utiliser cette approche si tes tests modifient l'état côté serveur en parallèle (documentation sur l'authentification).

Par quoi commencer. Prends un test Selenium qui marche et que tu connais bien, puis réécris-le dans Playwright en supprimant toutes les attentes explicites. Compare ensuite les deux : ce qu'il reste à écrire t'indique ce que l'outil fait à ta place. Mon conseil pour une migration : commence par un parcours critique plutôt que par toute la suite, et garde l'ancienne suite en service tant que la nouvelle ne t'a pas convaincu.

Parcours 2 : tu viens du test manuel

Ta force, c'est de savoir ce qui peut mal tourner pour un utilisateur. C'est la compétence la plus difficile à acquérir, et aucun outil ne la remplace. Il te reste à apprendre le code, et seulement assez pour exprimer ce que tu sais déjà vérifier.

Ce que tu gardes. Ton sens du risque, ta capacité à écrire un cas avec un résultat attendu précis, ton œil pour les cas limites. Tout cela sert directement à choisir quoi automatiser et quoi vérifier.

Ce que tu désapprends, trois réflexes.

1. Traduire un cas manuel étape par étape. Un cas manuel de trente étapes qui vérifie six choses ne devient pas un test automatisé de trente lignes. Il se découpe : un test par risque, avec une vérification claire dans chacun.
2. Livrer ce que l'enregistreur a produit. Playwright propose npx playwright codegen, qui enregistre tes actions et génère le code, avec des assertions de visibilité, de texte et de valeur. Il privilégie les locators par rôle, par texte et par test id. La documentation recommande de relire et d'améliorer le test généré si nécessaire (documentation de codegen). Utilise-le pour apprendre à quoi ressemble le code, pas pour te dispenser de le comprendre.
3. Oublier le await. Presque chaque ligne d'un test Playwright commence par await. Sans lui, le test passe à la ligne suivante sans attendre le résultat, et les échecs qui en découlent sont déroutants. Ce réflexe s'acquiert vite, mais il explique beaucoup de premières frustrations.

Voici un cas manuel, puis le test qui en sort après découpage, sur une boutique en ligne fictive (URL et libellés inventés) :

• Cas manuel : se connecter, chercher un casque audio, l'ajouter au panier, aller au paiement, saisir une carte refusée, vérifier le message d'erreur et vérifier que la commande est toujours modifiable.
• Ce que tu en tires : un test, un risque, « un paiement refusé laisse la commande modifiable ». La connexion et la recherche relevent de la préparation, pas de la vérification.

Par quoi commencer. Choisis un cas manuel que tu exécutes souvent, écris en une phrase le risque qu'il couvre, enregistre-le avec codegen, puis réécris le résultat pour qu'il ne vérifie plus que ce risque. Apprends le minimum de code utile au départ : variables, fonctions, imports, async et await. Le reste viendra avec la pratique.

Parcours 3 : tu viens du développement

Le code ne te fait pas peur, et TypeScript non plus : la documentation indique qu'il fonctionne sans configuration particulière. Tu progresseras vite sur la syntaxe. Le risque est ailleurs : tu vas écrire des tests comme tu écris du code, et un test de bout en bout obéit à d'autres règles.

Ce que tu gardes. Ta lecture de code, ton goût du refactoring, ta connaissance des tests unitaires et d'intégration. Tu sais aussi déjà ce qui se teste mieux ailleurs : une règle de calcul n'a pas sa place dans un parcours de bout en bout.

Ce que tu désapprends, trois réflexes.

1. Tester l'implémentation. Tu connais la structure de la page, donc tu es tenté de t'y accrocher. La documentation recommande de tester ce que l'utilisateur voit et fait, pas des détails d'implémentation comme le nom d'une fonction ou la classe CSS d'un bouton (bonnes pratiques Playwright).
2. Tout simuler. Simuler une réponse avec page.route est utile pour ce que tu ne contrôles pas, comme un prestataire de paiement. Si tu simules aussi ta propre API, ton test vérifie ta simulation plutôt que ton application.
3. Abstraire trop tôt. Avec un réflexe de développeur, tu vas vouloir factoriser dès le deuxième test. Demande-toi à quel moment l'abstraction coûte moins cher que la duplication qu'elle remplace, plutôt que de décider d'avance pour ou contre le Page Object.

Le premier point se voit bien sur une ligne de code. Sur une liste de panier fictive :

// Accroché à l'implémentation : casse si l'ordre ou les classes changent.
page.locator('.cart-item:nth-child(2) .remove');

// Accroché à ce que voit l'utilisateur : la ligne du casque audio et son bouton.
page
  .getByRole('listitem')
  .filter({ hasText: 'Casque audio' })
  .getByRole('button', { name: 'Retirer' });

Le second locator dit ce qu'il cherche. Si un produit s'insère avant le casque, il continue de fonctionner.

Par quoi commencer. Écris un test sur un parcours que tu connais, sans aucun sélecteur CSS. Si tu bloques sur un élément, c'est souvent que la page manque de rôles ou de libellés accessibles : c'est une information utile pour l'équipe, pas seulement pour ton test.

Apprendre seul ou te faire accompagner

Les trois parcours en un coup d'œil :

Une fois le premier exercice fait, voici un plan d'apprentissage que je te propose, quel que soit ton point de départ. Il vaut pour une première montée en compétence, pas pour une durée fixée :

1. Un test sur un parcours simple, relu ligne par ligne.
2. Un parcours critique complet, avec des tests isolés et une connexion réutilisée via un projet setup.
3. Un échec volontaire, lu avec le trace viewer, pour savoir diagnostiquer sans relancer.
4. Une exécution en intégration continue, avec un responsable du rapport.

Quand la documentation suffit. Tu as un développeur ou un collègue qui relit ton code, un vrai projet sur lequel t'entraîner et du temps régulier. La documentation de Playwright est bien faite, et un parcours autonome fonctionne dans ces conditions.

Quand un accompagnement fait gagner du temps. Personne ne relit ton code, tu apprends sur ton temps libre, tu dois livrer une suite à une équipe, ou tu te retrouves à bloquer sur les mêmes erreurs. Un accompagnement t'apporte alors un regard extérieur qui t'évite de construire dans la mauvaise direction pendant des semaines. Il ne remplace ni la pratique ni la lecture de la documentation.

Mission Playwright : pour quel parcours ?

Matthieu Bridoux a conçu Mission Playwright. D'après la page de la formation, elle part des bases et s'adresse d'abord aux testeurs manuels qui passent à l'automatisation. Elle correspond donc au deuxième parcours de cet article.

Pour les deux autres, la page ne dit pas que le programme a été pensé pour toi, et je ne l'affirmerai pas à sa place. Si tu viens de Selenium ou du développement, regarde le programme module par module et demande à Matthieu ce qu'il t'apporterait à ton niveau avant de t'engager. Une formation qui revient sur ce que tu sais déjà te fait perdre du temps, et mieux vaut le savoir avant de payer qu'après.

À retenir

• Tes compétences de test restent : ce qui change, ce sont trois mécanismes de l'outil (attente automatique, contexte isolé par test, locators par rôle).
• Depuis Selenium, le plus rentable est de supprimer tes attentes explicites et tes utilitaires, pas de les porter.
• Depuis le test manuel, découpe tes cas en un risque par test et relis tout ce que codegen produit.
• Depuis le développement, accroche tes locators à ce que l'utilisateur voit et simule seulement ce que tu ne contrôles pas.
• Avant de te former, compare le programme à ton point de départ, pas seulement à ton envie d'apprendre.

FAQ

Dois-je repartir de zéro en passant à Playwright ?

Non. Tes compétences de test (choix du risque, données, lecture d'un échec) s'appliquent telles quelles. Ce qu'il faut réapprendre tient à l'outil : la manière dont il attend, isole les tests et désigne les éléments.

Faut-il connaître TypeScript ?

Pas pour démarrer. La documentation indique que TypeScript fonctionne sans configuration particulière et qu'aucune expérience préalable n'est nécessaire. Playwright existe aussi pour Python, Java et .NET, avec sa propre documentation pour chacun. Choisis le langage que ton équipe sait relire.

Que faire de mes tests Selenium existants ?

Garde les scénarios et les risques qu'ils couvrent, réécris le code. Commence par un parcours critique et laisse l'ancienne suite en place jusqu'à ce que la nouvelle te convainque.

Codegen suffit-il pour apprendre ?

Il montre à quoi ressemble le code et choisit des locators par rôle, par texte ou par test id. Il ne décide pas à ta place de ce qui mérite d'être testé, et la documentation recommande de relire et d'améliorer le test généré.

Mission Playwright convient-elle à mon profil ?

La page de la formation vise d'abord les testeurs manuels, avec un parcours de 12 semaines qui part des bases. Si tu viens de Selenium ou du développement, demande à Matthieu ce que le programme t'apporterait avant de t'engager.

Aller plus loin avec Mission Playwright

Si tu es testeur manuel et que tu veux passer à l'automatisation avec Playwright, regarde le programme de Mission Playwright et vérifie qu'il correspond à ton niveau et à ton objectif : Découvrir Mission Playwright

Mention : partenariat commercial avec Matthieu Bridoux.

Plus d’articles comme celui-ci