coverage

À propos coverage

Cette compétence analyse les lacunes en matière de testcoverage au sein d'une application, en mettant l'accent sur les tests de bout en bout et les tests Playwright. Elle résout le problème lié au manque de visibilité sur ce qui est réellement testé en cartographiant toutes les surfaces testables (routes, composants, points de terminaison API et flux utilisateur critiques) et en les comparant aux tests existants, ce qui permet aux équipes d’identifier les lacunes de leur coverage.

Le workflow utilise un sous-agent « Explore » pour répertorier les chemins d’accès et les pages (répertoire de l’application Next.js, React Router, Vue Router, etc.), les composants interactifs et les points de terminaison API, puis analyse les fichiers `*.spec.ts`/`*.spec.js` existants afin de déterminer quelles pages, quels composants et quels points de terminaison sont testés. Il génère un tableau matriciel « coverage » indiquant les statuts «couvert», «partiel» ou «manquant», hiérarchise les zones non couvertes en fonction de leur impact métier (critique, élevé, moyen, faible) et propose un plan de test concret précisant le nombre de tests requis, un modèle recommandé et une estimation de l’effort nécessaire. Il peut, en option, générer automatiquement des tests pour les principales lacunes en exécutant la commande associée `/pw:generate`.

Il s’adresse aux ingénieurs assurance qualité et aux développeurs utilisant Playwright qui souhaitent disposer d’une vue structurée et hiérarchisée de l’ coverage plutôt que d’un simple pourcentage brut. Il lit les fichiers source et de test et peut déclencher la génération de tests, mais son analyse propre consiste en une inspection en lecture seule de la base de code et produit des rapports et des recommandations.

FAQ

Que fait cette compétence ?

Elle cartographie les routes, les composants, les points de terminaison API et les flux utilisateur d’une application, les compare aux tests existants, puis génère une matrice d’ coverage s hiérarchisée et un plan de test.

Sur quel framework de test repose-t-elle ?

Les tests de bout en bout Playwright ; elle analyse les fichiers *.spec.ts / *.spec.js et s’intègre à une commande associée /pw:generate.

Comment les lacunes sont-elles classées par ordre de priorité ?

En fonction de l’impact métier : les domaines critiques comme l’authentification et les paiements en premier, puis les opérations CRUD et la navigation destinées aux utilisateurs, ensuite les paramètres et les cas limites, et enfin les pages statiques de faible valeur.

Peut-il écrire les tests manquants ?

En option. Après avoir signalé les lacunes, il peut demander s’il faut générer des tests pour les N lacunes les plus importantes et lancer /pw:generate avec un modèle recommandé.

Modifie-t-il le code pendant l’analyse ?

L’analyse d’ coverage e en elle-même est en lecture seule ; elle inspecte les définitions de routes, les composants et les fichiers de spécifications. La génération de tests est une étape distincte, à activer manuellement.