Playwright Codegen enregistre vos interactions avec le navigateur et génère du code TypeScript fonctionnel en temps réel.
Ce que codegen génère vraiment
Codegen est l'enregistreur de tests intégré de Playwright. Lancez-le avec une seule commande, interagissez avec une page dans le navigateur qui s'ouvre. Un panneau sur le côté écrit le TypeScript (ou JavaScript, Python, Java ou C#) correspondant au fur et à mesure.
Ce que vous obtenez en sortie est un fichier .spec.ts contenant :
- Des appels
page.goto()pour chaque navigation - Des méthodes d'action comme
click(),fill(),check()etselectOption()pour chaque interaction - Des locators pour chaque élément touché, sélectionnés automatiquement selon la stratégie de locators de Playwright
- Une assertion basique à la fin si vous avez utilisé l'outil d'assertion dans l'inspecteur
Le code généré est exécutable immédiatement. Collez-le dans un fichier de test et lancez-le avec npx playwright test ; dans la plupart des cas il passe du premier coup. La valeur n'est pas que la sortie soit parfaite : c'est qu'en moins de deux minutes vous avez un squelette fonctionnel au lieu de trente.
Lancer codegen sur lab.becomeqa.com
Lancez codegen sur n'importe quelle URL :
npx playwright codegen https://lab.becomeqa.comDeux fenêtres s'ouvrent simultanément. La première est un navigateur Chromium standard affichant la page cible. La seconde est le Playwright Inspector : une fenêtre séparée avec un panneau de code, un bouton d'enregistrement et un sélecteur de locators.
Pas besoin d'un projet spécial pour ça. Codegen fonctionne entièrement en dehors d'un projet Playwright. Si vous êtes dans un répertoire de projet, le code généré respecte le langage configuré. Sinon, il génère du TypeScript par défaut.
Pour générer du code dans un langage spécifique :
# JavaScript
npx playwright codegen --target javascript https://lab.becomeqa.com
# Python
npx playwright codegen --target python https://lab.becomeqa.com
# Java
npx playwright codegen --target java https://lab.becomeqa.comPour cibler un navigateur spécifique plutôt que le Chromium par défaut :
npx playwright codegen --browser firefox https://lab.becomeqa.com
npx playwright codegen --browser webkit https://lab.becomeqa.comLe flag --browser est utile quand vous suspectez des différences de locators entre Chromium et WebKit, ou quand vous construisez un test ciblant spécifiquement un comportement Firefox.
L'interface codegen : trois outils à connaître
Le Playwright Inspector vous donne trois choses à comprendre avant de commencer l'enregistrement.
Le bouton Record démarre et arrête l'enregistrement. Quand il est actif (rouge), chaque interaction dans la fenêtre du navigateur est capturée en code. Cliquez à nouveau pour mettre en pause sans fermer la session. Cela vous permet de naviguer manuellement jusqu'à un état difficile à atteindre (comme ouvrir une modal ou naviguer plusieurs pages en profondeur). Reprenez l'enregistrement une fois que vous y êtes. Le sélecteur de locators (l'icône en forme de viseur) bascule le navigateur en mode inspection. Déplacez votre curseur sur n'importe quel élément et l'Inspector vous montre le locator que Playwright génèrerait, ainsi qu'un aperçu du nombre d'éléments correspondant. Vert signifie une seule correspondance. Jaune signifie plusieurs correspondances : ce locator est ambigu et ne devrait pas être utilisé dans un test. Le panneau d'assertions (l'icône de case à cocher) permet d'ajouter des assertions pendant l'enregistrement. Cliquez dessus, puis cliquez sur un élément dans le navigateur, et codegen insère une assertiontoBeVisible() dans le code. Vous pouvez aussi asserter le contenu texte ou l'état coché depuis le menu déroulant qui apparaît. C'est l'une des fonctionnalités les plus sous-utilisées : les débutants enregistrent souvent des actions sans rien asserter.
Pourquoi codegen préfère getByRole
Quand vous cliquez sur un bouton intitulé "Login", codegen ne génère pas page.locator('button.login-btn'). Il génère page.getByRole('button', { name: 'Login' }).
C'est intentionnel. La stratégie de locators de Playwright priorise les locators dans cet ordre :
1. getByRole : correspond au rôle ARIA et au nom accessible
2. getByLabel : pour les champs de formulaire associés à un label
3. getByPlaceholder : pour les champs avec du texte placeholder
4. getByText : pour les éléments non interactifs
5. getByTestId : pour les éléments avec un attribut data-testid
6. CSS ou XPath : en dernier recours
getByRole arrive en premier pour sa robustesse. La classe CSS d'un bouton peut changer quand un designer met à jour la feuille de styles. Sa position dans le DOM peut changer quand quelqu'un ajoute une fonctionnalité. Mais un bouton intitulé "Login" reste presque toujours intitulé "Login" : changer ça casserait l'interface pour de vrais utilisateurs. Les tests construits sur des locators accessibles sont plus stables parce qu'ils cassent pour les mêmes raisons que celles que les vrais utilisateurs remarqueraient.
Quand vous voyez codegen générer quelque chose comme page.locator('.btn-primary'), c'est un signe que l'élément n'a pas un bon nom accessible. Ça vaut la peine de s'arrêter et de demander si un attribut data-testid peut être ajouté à cet élément.
aria-label ou à s'assurer que l'élément label est correctement associé à son champ. Meilleure accessibilité et meilleurs locators de test viennent de la même source.Enregistrer un flux de connexion complet
Voici comment enregistrer un vrai test de connexion sur lab.becomeqa.com étape par étape.
Lancez codegen :
npx playwright codegen https://lab.becomeqa.comUne fois les deux fenêtres ouvertes et l'enregistrement actif, réalisez cette séquence dans le navigateur :
1. Cliquer sur le bouton Login dans la navigation
2. Remplir le champ email avec un compte de test
3. Remplir le champ mot de passe
4. Cliquer sur Submit
5. Attendre le chargement du tableau de bord
6. Utiliser le sélecteur d'assertion pour asserter que quelque chose sur le tableau de bord est visible
Après ces étapes, le panneau Inspector affiche quelque chose proche de ceci :
import { test, expect } from '@playwright/test';
test('test', async ({ page }) => {
await page.goto('https://lab.becomeqa.com/');
await page.getByRole('button', { name: 'Login' }).click();
await page.getByLabel('Email').fill('user@example.com');
await page.getByLabel('Password').fill('password123');
await page.getByRole('button', { name: 'Submit' }).click();
await expect(page.getByText('My Travel Items')).toBeVisible();
});Cliquez sur le bouton de copie dans l'Inspector, créez un fichier tests/login.spec.ts, et collez-le. Lancez-le :
npx playwright test tests/login.spec.ts --project=chromiumIl passe. Vous avez un test fonctionnel dans le temps qu'il a fallu pour traverser le flux de connexion une fois.
Nettoyer le code généré
Le code généré fonctionne, mais il n'est pas prêt pour la production. Trois choses nécessitent attention avant qu'il rejoigne une vraie suite de tests.
Les credentials en dur. Le code généré contient l'email et le mot de passe réels que vous avez tapés. Ils n'ont pas leur place dans le contrôle de version. Déplacez-les dans des variables d'environnement :import { test, expect } from '@playwright/test';
test('l\'utilisateur peut se connecter', async ({ page }) => {
await page.goto('/');
await page.getByRole('button', { name: 'Login' }).click();
await page.getByLabel('Email').fill(process.env.TEST_EMAIL!);
await page.getByLabel('Password').fill(process.env.TEST_PASSWORD!);
await page.getByRole('button', { name: 'Submit' }).click();
await expect(page.getByText('My Travel Items')).toBeVisible();
});Si vous avez une baseURL dans playwright.config.ts, remplacez aussi l'URL en dur dans page.goto() par '/'.
'test'. Renommez-le pour décrire le comportement vérifié, comme 'l\'utilisateur peut se connecter avec des identifiants valides'.
Les assertions manquantes. Codegen enregistre uniquement les actions et les assertions que vous avez explicitement ajoutées. Un test de connexion devrait asserter plus d'une chose. Pas seulement que le texte "My Travel Items" apparaît, mais aussi que l'URL a changé ou que le menu utilisateur affiche le bon email. Ajoutez-les manuellement.
Les locators répétitifs. Si vous avez enregistré un flux qui utilise le même locator cinq fois, extrayez-le dans une variable :
const emailInput = page.getByLabel('Email');
await emailInput.fill(process.env.TEST_EMAIL!);C'est mineur au niveau du test, mais cela devient essentiel quand les mêmes locators apparaissent dans plusieurs fichiers de test. C'est le moment de passer au Page Object Model. Pas avant d'en avoir besoin.
Enregistrer dans différents navigateurs et sauvegarder dans un fichier
Codegen prend en charge les trois moteurs de navigateurs de Playwright. Par défaut il utilise Chromium. Basculez sur Firefox ou WebKit quand vous avez besoin de locators qui fonctionnent sur tous les moteurs ou quand vous déboguez un comportement spécifique à un navigateur :
npx playwright codegen --browser webkit https://lab.becomeqa.comVous pouvez aussi sauvegarder le code généré directement dans un fichier au lieu de le copier depuis le panneau Inspector :
npx playwright codegen --output tests/login.spec.ts https://lab.becomeqa.comAvec --output, le fichier est écrit quand vous fermez la fenêtre Inspector. Si le fichier existe déjà, il est écrasé. Combinez ceci avec un langage cible pour générer des fichiers de test dans n'importe quelle stack supportée :
npx playwright codegen --target javascript --output tests/login.spec.js https://lab.becomeqa.comPour les équipes utilisant l'émulation de périphériques, codegen supporte --device pour simuler des viewports mobiles :
npx playwright codegen --device "iPhone 13" https://lab.becomeqa.comLe navigateur s'ouvre à la taille d'écran iPhone 13 avec le bon user agent. Le code généré inclut devices['iPhone 13'] dans les options de contexte.
Utiliser codegen comme explorateur de locators (sans enregistrer de tests)
L'une des utilisations les plus pratiques de codegen n'implique pas du tout d'enregistrer un test complet. Parfois vous avez juste besoin de trouver le bon locator pour un élément spécifique sans vouloir inspecter le DOM manuellement.
Lancez codegen, cliquez sur le sélecteur de locators, et déplacez votre curseur sur l'élément qui vous intéresse. L'Inspector vous montre le locator en temps réel. Il vous indique aussi combien d'éléments correspondent : une information critique avant de committer un locator dans un test.
npx playwright codegen https://lab.becomeqa.comUne fois le navigateur ouvert, appuyez sur le bouton d'enregistrement pour arrêter l'enregistrement afin de ne pas générer du code inutilement. Passez en mode sélecteur de locators et survolez les éléments. L'Inspector met à jour l'affichage du locator quand vous vous déplacez entre les éléments. Vous pouvez taper dans le champ de locator pour tester des variantes et voir combien d'éléments correspondent.
Ce workflow remplace des heures d'essais-erreurs dans le test runner. Vous validez un locator avant d'écrire le test, pas après qu'il échoue.
Les limites de codegen : ce qu'il ne peut pas enregistrer
Codegen gère la plupart des interactions utilisateur : clics, remplissage de formulaires, navigation, menus déroulants, cases à cocher, boutons radio. Plusieurs catégories sont mal gérées ou pas du tout.
Les téléchargements de fichiers. Codegen ne peut pas enregistrerpage.setInputFiles(). Quand vous cliquez sur un input de fichier et sélectionnez un fichier depuis votre système, codegen peut capturer le clic mais pas la sélection du fichier elle-même. Vous devez écrire le code de téléchargement de fichier manuellement.
Le glisser-déposer. Les événements HTML de drag-and-drop ne se traduisent pas proprement en enregistrements codegen. Le code généré peut montrer un clic sans le mouvement de glissement, ce qui signifie que l'interaction n'a silencieusement pas l'effet attendu. Utilisez page.dragAndDrop() ou simulez les événements individuels mousedown, mousemove et mouseup pour des interactions de glissement fiables.
Les attentes complexes. Codegen enregistre les actions au moment où vous les réalisez. Il n'enregistre pas le raisonnement implicite que vous faites en tant qu'humain ("J'ai attendu que le spinner disparaisse avant de cliquer"). Dans des environnements lents ou peu fiables, les tests générés peuvent échouer parce qu'ils s'exécutent plus vite que l'UI ne l'attend. Ajoutez des attentes explicites là où le flux le requiert :
await page.waitForLoadState('networkidle');
await expect(page.getByRole('progressbar')).toBeHidden();context.waitForEvent('page'). Codegen peut manquer entièrement le nouvel onglet.
Les états authentifiés. Codegen ne connaît pas l'authentification stockée. Si vous voulez que les tests démarrent déjà connectés, utilisez le storageState de Playwright pour sauvegarder les cookies de session après une connexion. Chargez ensuite cet état au début de chaque test. Codegen peut vous aider à enregistrer la connexion une fois, mais le pattern storage state doit être configuré manuellement.
Les flux OAuth et les connexions tierces. Tout flux qui redirige vers un fournisseur d'identité externe (Google, GitHub, Microsoft) est difficile à enregistrer avec codegen. Les locators existent sur une page tierce que vous ne contrôlez pas. Ces flux nécessitent une gestion séparée et souvent le mock du callback OAuth plutôt que de passer par le vrai fournisseur.
FAQ
Le code codegen est-il prêt à être committé directement ?Rarement. C'est un point de départ rapide, pas un test fini. Renommez toujours le test, supprimez les credentials en dur, vérifiez que les assertions sont significatives, et vérifiez que les locators correspondent à la structure d'accessibilité de la page.
Peut-on utiliser codegen sur une URL localhost ?Oui. npx playwright codegen http://localhost:3000 fonctionne exactement de la même façon. Si votre application nécessite une authentification pour atteindre la page à enregistrer, vous pouvez vous connecter manuellement avant de cliquer sur le bouton d'enregistrement.
Seulement s'il n'y a pas de meilleure option. Un sélecteur CSS comme .item-card:nth-child(2) cassera dès que la mise en page de la page changera. Essayez de comprendre pourquoi Playwright a utilisé CSS : l'élément manque probablement d'un nom accessible. Si vous ne pouvez pas en ajouter un, getByTestId avec un attribut data-testid est le meilleur choix suivant.
Aucune différence mesurable. L'enregistrement se produit dans le processus Inspector, pas dans le navigateur lui-même.
Peut-on faire une pause au milieu d'un enregistrement et naviguer manuellement ?Oui. Cliquez sur le bouton d'enregistrement pour mettre en pause, naviguez vers l'état nécessaire, puis cliquez à nouveau pour reprendre. Seules les interactions pendant que l'enregistrement est actif sont capturées.
Pourquoi codegen a-t-il générépage.locator('text=Submit') au lieu de getByRole ?
Cela se produit quand Playwright ne peut pas trouver un locator basé sur le rôle fiable. Il revient à la correspondance de texte. Vérifiez si l'élément est un bouton avec un nom accessible ; pour un élément bouton standard, il devrait générer getByRole('button', { name: 'Submit' }).
