Playwright MCP Expliqué: Laissez l'IA Écrire Vos Tests

Le Model Context Protocol (MCP) change la façon dont les assistants IA interagissent avec Playwright. Au lieu de décrire ce que vous voulez, MCP donne à l'IA l'accès à votre navigateur pour inspecter l'interface réelle. Les tests générés reflètent ce qui est vraiment là, avec des locators corrects dès la première exécution.

Ce qu'est MCP et pourquoi ça compte pour les tests

MCP (Model Context Protocol) est un protocole ouvert qui permet aux assistants IA de se connecter à des outils et sources de données externes. Anthropic l'a publié en 2024, et l'équipe Playwright a ajouté le support MCP officiel en 2025.

En pratique : quand vous utilisez un assistant IA connecté via MCP (comme Claude dans votre IDE), il peut ouvrir un navigateur et naviguer vers votre application. Il inspecte le DOM et comprend quels éléments existent, avant d'écrire une seule ligne de code de test.

Avant MCP, la génération de tests par IA fonctionnait comme ça :

1. Vous décrivez votre application en texte

2. L'IA génère du code basé sur la description

3. Vous découvrez que les locators sont faux parce que l'IA a imaginé une structure qui ne correspond pas à la réalité

4. Vous corrigez les locators manuellement

Avec MCP :

1. L'IA ouvre votre application dans un navigateur

2. L'IA inspecte la vraie structure DOM

3. L'IA génère du code en utilisant les vrais rôles, labels et data-testids

4. Les locators fonctionnent dès la première exécution (la plupart du temps)

La différence n'est pas que de la commodité. C'est un changement qualitatif dans la qualité du résultat.

Configurer Playwright MCP

Prérequis

Node.js 18 ou supérieur et un client IA compatible MCP (Claude Desktop, ou un IDE avec support MCP).

Installation

npm install -g @playwright/mcp

Ou ajoutez-le comme dépendance de projet :

npm install --save-dev @playwright/mcp

Connexion à Claude Desktop

Ajoutez le serveur MCP à votre configuration Claude Desktop. Ouvrez le fichier de config :

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp"]
    }
  }
}

Redémarrez Claude Desktop. Vous devriez voir un nouvel outil Playwright disponible dans le menu des outils.

Connexion à VS Code

Si vous utilisez une extension VS Code compatible MCP (comme l'extension Claude pour VS Code), la configuration est similaire : ajoutez le serveur dans les paramètres MCP de l'extension.

Ce que l'IA voit via MCP

Quand l'IA se connecte via Playwright MCP, elle a accès à :

Générer un test avec MCP

Voici à quoi ressemble une vraie session MCP. Vous ouvrez votre assistant IA, demandez d'écrire un test, et il se met au travail :

L'IA voit :

• Une barre de navigation avec un bouton "Login" (rôle : button, name : "Login")
• Une modale avec deux champs de saisie (label : "Username", label : "Password")
• Un bouton de soumission (rôle : button, name : "Submit")
• Après connexion : un titre avec le texte "My Travel Items"

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

test('l\'utilisateur peut se connecter avec des identifiants valides', async ({ page }) => {
  await page.goto('https://lab.becomeqa.com');
  
  await page.getByRole('button', { name: 'Login' }).click();
  await page.getByLabel('Username').fill('admin@becomeqa.com');
  await page.getByLabel('Password').fill('testpass123');
  await page.getByRole('button', { name: 'Submit' }).click();
  
  await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
});

Les locators sont corrects parce que l'IA a regardé l'application réelle, pas une description. getByRole('button', { name: 'Login' }) fonctionne parce que l'IA a vérifié que ce bouton existe avec exactement ce nom accessible.

Lancer les tests générés par MCP avec votre setup existant

MCP génère des tests Playwright standard. Ils s'intègrent à votre suite de tests existante sans aucune modification :

# S'exécute comme n'importe quel autre test
npx playwright test tests/login.spec.ts

# Ou lancer tous les tests
npx playwright test

Les tests générés utilisent le même playwright.config.ts, les mêmes reporters, le même pipeline CI. MCP est un outil de génération, pas un runner de tests séparé.

Workflow pratique : développement de tests assisté par IA

Voici un workflow qui fonctionne bien en pratique :

Demandez à l'IA d'écrire un test pour un scénario spécifique. Soyez précis sur ce que vous voulez vérifier. Pas juste "tester la connexion", mais plutôt "vérifier que la connexion avec des identifiants valides affiche le tableau de bord avec le nom de l'utilisateur dans la navigation".

Vérifiez :

• Les locators utilisent-ils getByRole / getByLabel / getByTestId ? (Bien)
• Y a-t-il des schémas getByXpath ou locator('div.some-class') ? (Mauvais, ça cassera)
• Y a-t-il des appels page.waitForTimeout(2000) ? (Mauvais, utilisez await expect(...) à la place)
• Le test a-t-il des assertions significatives, pas juste "la page s'est chargée" ?

npx playwright test tests/login.spec.ts --headed

Regardez-le s'exécuter. Est-ce que ça correspond à ce que vous attendiez ?

Si quelque chose ne va pas, dites à l'IA ce qui s'est passé. "Le test échoue à l'étape de la modale. Il semble que la modale prenne un moment pour apparaître. Pouvez-vous ajouter une vraie attente ?" L'IA peut revenir sur l'application et inspecter ce qui se passe.

Une fois que le test du chemin nominal fonctionne, demandez des tests négatifs : "Maintenant, écris un test pour le cas où le mot de passe est incorrect." L'IA peut ainsi interagir avec l'application pour voir ce qui se passe réellement, quel message d'erreur apparaît, où il apparaît, comment il est formulé.

Ce que MCP génère bien vs mal

• Flux nominaux avec une structure d'interface claire
• Interactions de formulaires (fill, select, click)
• Assertions sur le texte visible et les titres
• Interactions avec les modales et boîtes de dialogue
• Tests pour les applications accessibles avec un HTML sémantique correct

• Scénarios complexes dépendant de l'état ("l'utilisateur a exactement 3 éléments dans un état spécifique")
• Tests qui dépendent de données backend préparées
• Tests de layout visuel (cet élément est-il bien positionné ?)
• Conditions de course et scénarios sensibles au timing
• Tests nécessitant un setup/teardown de base de données ou d'API

Pour la deuxième catégorie, le code généré par IA vous donne une structure de départ qui nécessite un raffinement manuel.

MCP vs génération de code IA traditionnelle

| Aspect | MCP | Génération par prompt |

|--------|-----|----------------------|

| Précision des locators | Élevée, depuis le vrai DOM | Variable, depuis une description |

| Taux de réussite à la première exécution | Fonctionne généralement | Nécessite souvent des corrections |

| Prérequis | Accès navigateur à l'app | Simple description textuelle |

| Utile quand | L'app tourne en local | L'app n'est pas encore construite |

Les deux approches ont leur place. Pour tester une application déployée, MCP est nettement meilleur. Pour écrire des tests avant que l'application existe (développement piloté par les tests), la génération par prompt depuis une spécification reste utile.

Utiliser MCP en CI

MCP est un outil de développement, pas un outil CI. Le workflow est :

1. Utilisez MCP en local pour générer et itérer sur les tests

2. Committez les tests générés dans votre dépôt

3. La CI exécute les tests en mode headless avec Playwright standard

Vous ne lancez pas MCP en CI. Vous lancez les tests que MCP vous a aidé à écrire.

FAQ

Toute application web accessible via un navigateur. Peu importe que le frontend soit en React, Vue, Angular ou HTML simple. MCP fonctionne au niveau du navigateur, pas du framework.

Expérimentalement, oui. Vous pouvez demander à l'IA de regarder l'application actuelle et corriger un test qui échoue suite à un changement d'interface. En pratique, cela fonctionne bien pour les mises à jour de locators mais moins bien pour les changements structurels du flux de test.

Le package @playwright/mcp est open source et gratuit. Vous avez besoin d'un client IA compatible MCP. Claude Desktop (Anthropic) a des niveaux gratuit et payant. Les autres clients compatibles varient.

Les deux. Précisez ce que vous voulez : "Écris ce test en TypeScript avec le mode strict" ou l'IA utilisera celui qui correspond à la config de votre projet existant.