Grille de revue des tests générés par l'IA
Un assistant IA écrit un test Playwright en quelques secondes. Le test compile, s'exécute, passe au vert… et vérifie parfois très peu de choses. Cette grille en 7 points sert à relire un test généré comme on relit le code d'un collègue, avant de le fusionner. Gratuite, imprimable, sans inscription.
Elle complète notre guide Playwright MCP : tester avec l'IA, qui montre comment un assistant explore une page puis génère un test.
Les 7 points de la grille
1. L'assertion vérifie un résultat métier
Pourquoi : l'IA vérifie volontiers ce qu'elle vient de faire (un clic a eu lieu, une page s'est chargée), pas ce que le métier attend. Un test sans vraie assertion passe même quand la fonctionnalité est cassée.
Avantawait page.getByRole('button', { name: 'Valider la commande' }).click();
await expect(page).toHaveURL(/\/commande/);
Après
await page.getByRole('button', { name: 'Valider la commande' }).click();
await expect(page.getByRole('heading', { name: 'Commande confirmée' })).toBeVisible();
await expect(page.getByTestId('montant-total')).toHaveText('49,90 €');
Question à se poser : si la fonctionnalité renvoyait un mauvais résultat, ce test échouerait-il ?
2. Des locators accessibles, pas de CSS fragile
Pourquoi : un sélecteur fondé sur la structure HTML casse à la première refonte. Les locators par rôle, libellé ou identifiant de test décrivent ce que voit l'utilisateur et survivent aux changements de mise en page.
Avantawait page.locator('div.form > div:nth-child(2) > input').fill('lea@example.com');
await page.locator('//button[contains(@class,"btn-primary")]').click();
Après
await page.getByLabel('Adresse e-mail').fill('lea@example.com');
await page.getByRole('button', { name: 'Se connecter' }).click();
Question à se poser : le test casserait-il si un développeur ajoutait une simple balise autour du formulaire ?
3. Des données de test dédiées, recréées à chaque exécution
Pourquoi : pendant l'exploration, l'IA réutilise ce qu'elle trouve sur la page : un compte existant, une commande déjà créée. Le test dépend alors d'un état qui changera, et il échoue au hasard ou en cascade.
Avant// compte trouvé pendant l'exploration, partagé par tous les tests
await page.getByLabel('Adresse e-mail').fill('jean.dupont@example.com');
Après
test.beforeEach(async ({ request }) => {
// compte créé par l'API avant chaque test, propre à ce test
const res = await request.post('/api/test/utilisateurs', {
data: { email: `test-${Date.now()}@example.com` },
});
expect(res.ok()).toBeTruthy();
});
Question à se poser : ce test passerait-il encore s'il était exécuté seul, ou en parallèle avec les autres ?
4. Les secrets restent hors du prompt et du code
Pourquoi : un mot de passe écrit dans le prompt reste dans l'historique de l'assistant ; écrit dans le code, il part dans le dépôt Git. Pour l'exploration, Playwright MCP accepte un fichier de secrets au format dotenv (option --secrets) ; pour les tests, on lit des variables d'environnement.
await page.getByLabel('Mot de passe').fill('MotDePasse123!');
Après
await page.getByLabel('Mot de passe').fill(process.env.TEST_USER_PASSWORD!);
Question à se poser : que verrait un inconnu qui lirait ce fichier, ou l'historique de la conversation avec l'assistant ?
5. Jamais sur la production
Pourquoi : un assistant qui clique tout seul peut soumettre un formulaire, supprimer une donnée ou déclencher un paiement. L'exploration et les tests se font sur un environnement de test, avec un profil de navigateur isolé (option --isolated de Playwright MCP) plutôt qu'une session réelle.
// playwright.config.ts
use: { baseURL: 'https://www.mon-site.fr' },
Après
// playwright.config.ts
use: { baseURL: process.env.BASE_URL ?? 'http://localhost:3000' },
Question à se poser : sur quelle URL l'assistant a-t-il réellement travaillé, et avec quel compte ?
6. Une exploration limitée à un parcours
Pourquoi : chaque instantané de page et chaque description d'outil occupent le contexte du modèle. Une consigne vague (« teste tout le site ») coûte cher en jetons et produit des tests superficiels. Une consigne précise, un parcours à la fois, donne de meilleurs tests.
AvantTeste l'application et écris tous les tests nécessaires.
Après
Ouvre http://localhost:3000/login. Décris les champs et les messages.
Essaie un mot de passe incorrect et rapporte le message exact.
N'ouvre aucune autre page et ne soumets aucun autre formulaire.
Question à se poser : la consigne donnée à l'assistant tenait-elle en un parcours, avec un résultat attendu ?
7. Le test a échoué au moins une fois, volontairement
Pourquoi : un test qui n'a jamais été vu en échec ne prouve rien. Casser volontairement la fonctionnalité (ou l'assertion) une fois permet de vérifier qu'il détecte bien une régression, puis de tout remettre en place.
Avant// test généré, exécuté une fois, vert : fusionné tel quel
Après
// vérification ponctuelle : on fausse le résultat attendu…
await expect(page.getByTestId('montant-total')).toHaveText('0,00 €');
// …le test doit échouer ; puis on rétablit la valeur correcte.
Question à se poser : ai-je vu ce test en rouge au moins une fois, pour la bonne raison ?
Les 5 défauts à repérer en premier
- Sélecteurs fragiles : CSS ou XPath fondés sur la structure de la page au lieu de
getByRole,getByLabelougetByTestId. - Assertions vides : le test vérifie qu'une action a eu lieu, pas son résultat.
- Attentes fixes :
page.waitForTimeout(3000)au lieu d'une assertion qui réessaie, commeawait expect(locator).toBeVisible(). - Données codées en dur : comptes, identifiants et montants recopiés depuis l'exploration et partagés entre tests.
- Seul le cas nominal : aucun cas d'erreur, de champ vide ou de valeur limite.
Comment utiliser cette grille
- Imprimez le PDF ou gardez cette page ouverte pendant la revue de la pull request.
- Passez les 7 points pour chaque test généré, pas seulement pour le premier.
- Un point non coché bloque la fusion : on corrige le test, ou on note pourquoi le point ne s'applique pas.
- Ajoutez la grille à votre définition de « terminé » pour tout test écrit avec un assistant.
Pour concevoir les cas de test eux-mêmes avant de les automatiser, partez d'un cahier de recette : résultats attendus écrits avant l'exécution, données fixées, statuts clairs.
Questions fréquentes
Pourquoi relire un test généré par l'IA s'il passe ?
Parce qu'un test qui passe n'est pas forcément un bon test. Un assistant vérifie souvent qu'une action a eu lieu plutôt que le résultat attendu par le métier, utilise des sélecteurs fragiles ou des données partagées. La revue garantit que le test détecte réellement une régression.
Cette grille fonctionne-t-elle avec Copilot, Claude Code ou Cursor ?
Oui. Elle porte sur le test produit, pas sur l'outil qui l'a écrit : elle s'applique quel que soit l'assistant, et aussi aux tests écrits à la main.
Les exemples sont-ils propres à Playwright ?
Les exemples de code sont en Playwright et TypeScript, mais les 7 points valent pour Cypress, Selenium ou un autre outil : résultat métier vérifié, locators robustes, données isolées, secrets protégés, environnement de test, consigne précise, test vu en échec.
Puis-je utiliser cette grille dans mon équipe ou en cours ?
Oui, elle est gratuite. Vous pouvez l'imprimer et la partager en citant la source : AutomationDataCamp, automationdatacamp.com/grille-revue-tests-ia.
Apprendre à écrire les tests que l'IA ne sait pas concevoir
Pour relire un test généré, il faut savoir à quoi ressemble un bon test. Commencez par notre mini-cours Playwright gratuit, puis la formation Playwright certifiante : locators, assertions, données de test, tests d'API, CI et IA appliquée au test.
Guide complet de l'outil : Playwright en français.
Grille rédigée par l'équipe ADC avec l'aide de l'IA ; options de Playwright MCP vérifiées dans sa documentation officielle.