Playwright et MCP : comment un agent IA teste l'UI et la base de données sans assertions SQL manuelles

Un toast vert après avoir cliqué sur le bouton "Passer la commande" ne signifie pas que la commande a été réellement créée. Si la transaction a été annulée, la file d'attente a perdu un message et l'interface affichait toujours "succès", le test de bout en bout donne une fausse impression de fiabilité. C'est pourquoi de plus en plus d'équipes se tournent vers la vérification full-stack, où non seulement l'interface est vérifiée, mais aussi l'état réel des données dans la base de données.

Dans l'approche classique, cette vérification nécessite que l'infrastructure de test ait un accès direct à la BD via un ORM ou un pilote bas niveau. Ensuite commencent les frais généraux: des identifiants distincts, la configuration de la connexion, les assertions SQL manuelles, la maintenance des requêtes à chaque modification du schéma. Formellement cela résout le problème, mais le coût augmente avec le nombre de scénarios.

Chaque nouveau test de bout en bout devient non seulement une vérification du comportement de l'utilisateur, mais un mini-projet de maintenance du code de test. L'article couvre un modèle plus léger: un agent IA travaille séquentiellement avec deux serveurs MCP à la fois. D'abord, par Playwright, il exécute un scénario dans le navigateur comme un utilisateur ordinaire—remplit le panier, effectue le paiement, clique sur le bouton de confirmation et capture les indicateurs clés du résultat.

Ensuite, le même agent bascule vers un serveur qui peut lire la structure de la base de données et répondre aux requêtes de vérification sans que le testeur n'écrive SQL manuellement. Essentiellement, l'agent n'a qu'à formuler exactement ce qui doit être confirmé: l'enregistrement de la commande existe-t-il, les articles correspondent-ils, le solde du produit a-t-il été déduit, le statut du paiement a-t-il changé. Cette approche ferme l'écart principal entre "l'interface a montré le succès" et "l'opération commerciale s'est réellement déroulée."

L'agent peut faire correspondre les données de l'interface aux enregistrements dans les tableaux, vérifier les effets secondaires et même tenir compte de l'asynchronisme si le système n'écrit pas immédiatement dans la BD. Pour les équipes produit, c'est particulièrement important dans les scénarios où un bouton de l'utilisateur déclenche une chaîne d'actions: création de commande, réservation d'inventaire, écriture dans le système logistique, mise à jour du statut client. C'est dans ces endroits que naissent le plus souvent des bugs coûteux, ceux que les tests d'interface ordinaires ne détectent pas.

La valeur pratique de ce modèle est qu'il abaisse la barrière pour les tests full-stack. Les équipes n'ont pas besoin de traîner un ORM dans les tests juste pour quelques vérifications et dupliquer la connaissance du schéma de la base dans le code d'assertion. À la place, il y a une couche de vérification unique au niveau de l'intention: "après le paiement, un enregistrement de commande devrait apparaître," "le nombre d'articles devrait correspondre," "le solde de l'entrepôt devrait diminuer d'une unité."

Si le schéma change, la maintenance se déplace plus proche du serveur MCP ou de la description de l'accès aux données, plutôt que d'être étalée sur des dizaines de tests. En conséquence, les tests deviennent plus courts, plus clairs et plus proches du langage métier. En même temps, ce scénario ne supprime pas la discipline d'ingénierie de base.

Vous ne pouvez pas vous fier uniquement à l'agent IA: les tests unitaires et les tests d'intégration sont toujours nécessaires pour localiser rapidement les erreurs au niveau de la fonction, du service et du contrat. L'accès à la base de données pour l'agent doit être limité, de préférence en lecture seule et uniquement dans un environnement de test. Des mesures de prévisibilité sont également nécessaires: des données de test stables, des règles de sélection claires, une protection contre le fait que l'agent vérifie accidentellement la mauvaise commande dans une base de données partagée.

Sinon, un outil pratique devient rapidement une source de défaillances bruyantes et difficiles à reproduire. La conclusion principale ici est simple: l'étape suivante dans l'évolution des tests de bout en bout est la transition de la vérification des écrans à la vérification des conséquences réelles des actions de l'utilisateur. La combinaison Playwright et MCP rend cette transition significativement moins chère car elle supprime le SQL manuel du travail quotidien du testeur et permet à une automatisation unique de parcourir le chemin du clic du bouton au fait d'un enregistrement dans la base de données.

Pour les équipes testant les paiements, les commandes, les réservations et autres transactions critiques, il ne s'agit pas seulement d'une technique pratique mais d'un moyen de réduire le nombre de faux positifs et de détecter les bugs plus tôt avant qu'ils ne s'échappent vers la production.