ce-test-browser

À propos ce-test-browser

Un workflow permettant d'exécuter des tests de navigateur de bout en bout sur les pages concernées par une pull request ou des modifications de branche, en utilisant exclusivement la ligne de commande (CLI) d'agent-browser. Il évite délibérément tout autre système d’automatisation de navigateur ou toute intégration MCP de navigateur ; dans Claude Code, il n’utilise pas les outils MCP de Chrome, et dans Codex, il ne remplace pas d’autres outils de navigation. agent-browser est utilisé pour ouvrir des pages, cliquer sur des éléments, remplir des formulaires, réaliser des captures d’écran et extraire le contenu affiché. Il accepte un argument qui peut être un numéro de PR, un nom de branche, le mot « current » ou un indicateur « --port ».

Le workflow vérifie d’abord si agent-browser est installé et s’arrête en indiquant d’exécuter /ce-setup s’il manque. Il demande ensuite s’il faut l’exécuter en mode « headed » ou « headless », sauf en mode pipeline où il utilise par défaut le mode « headless » sans blocage. La portée du test est déterminée à partir des fichiers modifiés à l’aide de `gh pr view` pour un numéro de PR, ou de `git diff` par rapport à la branche « main » pour la branche « current » ou une autre branche. Les fichiers modifiés sont mappés à des routes testables via une table de correspondances couvrant les vues Rails, les contrôleurs, les contrôleurs Stimulus, les ViewComponents, les mises en page, les feuilles de style, les helpers, ainsi que les chemins d’accès aux applications et composants Next.js, ce qui génère une liste d’URL à tester.

La gestion des ports distingue le mode manuel du mode pipeline. Elle détermine un port préféré à partir d’un argument --port explicite, d’instructions de projet contextuelles, des scripts dev/start du fichier package.json, des fichiers d’environnement, ou d’une valeur par défaut de 3000, en s’abstenant délibérément de rechercher un port dans le texte. En mode pipeline, il recherche vers le haut un port libre, car plusieurs agents peuvent s’exécuter en parallèle, et démarre un serveur de développement en arrière-plan si aucun n’est à l’écoute, en attendant jusqu’à 30 secondes ; en mode manuel, il utilise directement le port préféré et demande à l’utilisateur de démarrer le serveur s’il n’est pas en cours d’exécution. Pour chaque route concernée, il parcourt la page et capture un instantané interactif, en utilisant l’option --headed lorsque l’utilisateur a choisi de surveiller la page, puis vérifie les éléments clés tels que le titre ou l’en-tête de la page et les principaux éléments interactifs. Utilisez-le pour vérifier que les pages affectées par une modification s’affichent et se comportent toujours correctement.

FAQ

Quel outil d’automatisation de navigateur cette compétence utilise-t-elle ?

Exclusivement la CLI agent-browser. Elle n’utilise pas les outils Chrome MCP de Claude Code ni ne remplace d’autres outils de navigation dans Codex.

Que se passe-t-il si agent-browser n’est pas installé ?

Il invite l’utilisateur à exécuter la commande /ce-setup pour l’installation en cours, à installer agent-browser, puis à réessayer, avant de s’arrêter car la compétence ne peut pas fonctionner sans cet outil.

Comment détermine-t-elle les pages à tester ?

Elle récupère les fichiers modifiés à partir de la vue « gh pr » (pour une pull request) ou via « git diff » par rapport à la branche « main » (pour une branche ou la version actuelle), puis associe ces fichiers à des routes à l’aide d’un tableau de motifs de fichiers afin de générer une liste d’URL.

Comment le port du serveur de développement est-il choisi ?

Par ordre de priorité : un argument --port explicite, les instructions du projet dans le contexte, les scripts de développement dans package.json, les fichiers d'environnement tels que .env, puis la valeur par défaut 3000. Il ne recherche pas le port dans le texte.

Quelles sont les différences en mode pipeline ?

Il ignore la question « avec ou sans interface graphique » et utilise par défaut le mode sans interface graphique ; il recherche vers le haut un port réellement libre, car les agents peuvent s’exécuter en parallèle ; et il démarre automatiquement un serveur de développement en arrière-plan si aucun n’est à l’écoute.