generate

À propos de « generate »

Cette compétence, « generate », génère des tests Playwright de bout en bout prêts à être déployés à partir d’une user story, d’une URL, d’un chemin d’accès à un composant ou d’une description de fonctionnalité. Elle résout le problème lié à la rédaction manuelle de tests de navigateur fiables et conformes aux conventions : elle explore le projet existant pour identifier son répertoire de tests, son URL de base, ses fixtures et ses conventions relatives aux objets de page avant de générer quoi que ce soit, de sorte que le résultat s'adapte à la base de code cible plutôt qu'à un modèle générique.

Le workflow analyse ce qu’il faut tester, utilise un sous-agent « Explore » pour lire la configuration Playwright et les tests existants, sélectionne un modèle correspondant (authentification, CRUD, paiement, recherche, formulaires, tableau de bord, paramètres, onboarding, API, accessibilité) et l’adapte avec des sélecteurs et des données réels. Generate Les tests respectent des règles de qualité strictes : un ordre de priorité des localisateurs privilégiant getByRole, getByLabel et d’autres localisateurs sémantiques par rapport au CSS nu ; des assertions à réessai automatique axées sur le Web ; et une interdiction explicite des anti-modèles tels que waitForTimeout, les sélecteurs page.$ et l’utilisation inutile de page.evaluate. Il respecte les conventions du projet concernant TypeScript par rapport à JavaScript, les objets de page et les fixtures, et peut generate prendre en charge les objets de page, les fixtures et les fichiers de données de test lorsque cela est justifié. Enfin, il exécute les tests generate d à l’aide de la CLI Playwright et itère en cas d’échecs.

Il s’adresse aux développeurs web et aux ingénieurs QA qui utilisent Playwright et souhaitent une couverture e2e cohérente et facile à maintenir, generate d dans le style de leur propre projet. Parmi les cas d’utilisation, on peut citer le test des flux de connexion et de paiement, la validation des formulaires, les interfaces utilisateur de recherche et de filtrage, ainsi que le comportement des composants. La compétence est fournie avec un fichier SKILL.md et une bibliothèque patterns.md contenant des exemples concrets de tests pour l’authentification, les opérations CRUD et les flux de validation.

FAQ

Quelles entrées accepte-t-elle ?

Une user story, un chemin d’accès à un fichier de composant, une page ou une URL, ou encore un nom de fonctionnalité — par exemple « l’utilisateur peut se connecter avec son e-mail et son mot de passe » ou « src/components/UserProfile.tsx ».

Quel style de localisation et d’assertion impose-t-elle ?

Il privilégie les localisateurs sémantiques (getByRole, getByLabel, getByText, getByPlaceholder, getByTestId, dans cet ordre) et utilise toujours des assertions avec réessais automatiques « web-first » plutôt que l’extraction manuelle de texte.

Quels anti-modèles évite-t-il ?

Il n’utilise jamais page.waitForTimeout(), les sélecteurs page.$/page.$$, les sélecteurs CSS nus sauf en cas de nécessité absolue, ni page.evaluate() pour des tâches que les localisateurs peuvent effectuer.

Vérifie-t-il les tests qu’il écrit ?

Oui : il exécute le test d’generated avec la commande « npx playwright test --reporter=list », identifie toute erreur et corrige le test plutôt que l’application, en vous signalant les véritables problèmes de l’application.

S’adaptera-t-il aux conventions de mon projet ?

Il analyse le fichier playwright.config.ts et les tests existants pour s’adapter à l’utilisation de TypeScript ou de JavaScript, aux objets de page existants, aux fixtures personnalisées et aux répertoires de données de test.

Tous les fichiers