Audit de lacunes en tests

Trouvez les tests qui devraient exister mais n'existent pas, ou les tests qui existent mais ne prouvent pas le comportement important. Produisez des recommandations de tests concrètes et priorisées ancrées dans les chemins de code, les risques et les conventions de tests existantes.

Règles fondamentales

• Restez en lecture seule sauf si l'utilisateur demande explicitement d'ajouter des tests.
• Par défaut, effectuez un audit complet du référentiel quand l'utilisateur ne fournit pas de portée spécifique.
• Les audits complets du référentiel sont en largeur d'abord, puis limités en profondeur. Inventoriez le référentiel, classez les surfaces par risque, inspectez profondément autant de surfaces à haut risque que le tour le permet, et listez le reste sous Surfaces examinées mais non profondément inspectées avec un pointeur pour relancer un passage sur celles-ci. Indiquez les comptages de surface dans l'en-tête du rapport. Ne présentez jamais un balayage superficiel comme une couverture complète.
• Quand l'utilisateur nomme une route, une fonctionnalité, un workflow, une PR, une branche, un service, un paquet, un répertoire ou une autre portion du référentiel, limitez l'audit à cette portée et ses chemins de code directement connectés.
• Concentrez-vous sur la qualité de la couverture et la protection contre les régressions, non sur la chasse aux bugs en général.
• Ancrez chaque lacune dans un comportement, un chemin de code modifié, un risque ou un test existant faible.
• Préférez les cas de test exacts aux conseils de couverture génériques.
• Déduisez le style de test du référentiel avant de recommander des tests unitaires, d'intégration, de composant, de navigateur, de contrat ou de bout en bout.
• Séparez la couverture manquante confirmée des lacunes déduites.
• Ne traitez pas le pourcentage de couverture ligne/branche comme une preuve suffisante. La couverture comportementale importe davantage.
• Évitez de recommander des tests lents de bout en bout quand un test de niveau inférieur prouverait le comportement de façon fiable.

Entrées

Quand aucune portée n'est donnée, auditez l'ensemble du référentiel. Inventoriez les principales surfaces testables du référentiel et signalez quelles zones importantes n'ont pas de tests, n'ont pas assez d'assertions, ou ne sont couvertes qu'indirectement.

Acceptez toute portée de test spécifique, notamment :

• Demandes pull ou branches : audit test gaps in this PR, what tests should this branch add.
• Fonctionnalités : test gap audit uploads, what coverage is missing for billing.
• Routes/APIs : review tests for POST /orders, check auth tests around exports.
• Workflows : invite teammate -> accept invite -> set role -> revoke access.
• Corrections de bugs : what regression test should cover this fix.
• Suivi de sécurité ou docs : what tests prove the security audit fixes, do examples have tests.

Si la portée est floue, déduisez la plus petite limite utile et énoncez-la. Si aucune portée n'est indiquée, ne demandez pas ; procédez à un audit complet du référentiel. Posez une question seulement quand des portées différentes nécessiteraient des plans de test matériellement différents.

Flux de découverte

1. Établissez le contexte du référentiel.

   • Vérifiez git status --short.
   • Identifiez la pile, les exécuteurs de tests, les scripts de package, les vérifications CI, les noms de fichiers de test, le style de fixture, les mocks, les usines, les outils de navigateur, les conventions de test API, et les limites de monorepo.
   • Lisez les manifestes pertinents, les workflows CI, les configs de test, et les tests à proximité.

2. Mappez le comportement en révision.

   • Pour les audits complets du référentiel, inventoriez les principales surfaces d'application, paquets, routes, APIs, services, jobs, CLIs, schémas, intégrations et bibliothèques partagées avant de choisir les lacunes à haut risque à inspecter profondément.
   • Pour les PRs, inspectez les fichiers modifiés, les tests modifiés, et le code adjacent inchangé.
   • Pour les fonctionnalités, localisez les routes, les composants, les services, les modèles, les schémas, les jobs, les permissions, les intégrations, et les états visibles par l'utilisateur.
   • Identifiez les chemins heureux, les chemins d'échec, les cas limites, les limites de données, les limites d'auth/autorisation, le comportement de migration/config, et le comportement d'intégration externe.

3. Mappez la couverture existante.

   • Exécutez d'abord le scripts/coverage_map.py fourni quand il est disponible. Il détecte la framework de test et la convention de nommage, puis met en correspondance chaque fichier source par rapport aux tests par nom, chemin en miroir, et ce que les fichiers de test importent réellement, et retourne les fichiers non appariés classés avec des mots-clés de risque plus les fichiers de test qui ont des cas mais presque pas d'assertions. Le chemin est relatif au répertoire de cette compétence, qui varie selon l'hôte. Utilisez python si python3 n'est pas sur PATH.
   • python <skill-dir>/scripts/coverage_map.py --top 25, ou --format json pour filtrer vous-même les résultats.
   • Le matcher est heuristique et ne peut pas voir la couverture qui arrive via des fixtures, des tests de bout en bout, ou l'indirection. Traitez un fichier non apparié comme une piste, et cherchez le nom du module pour confirmer avant de le signaler comme P0 ou P1. Signalez une lacune comme confirmée uniquement après l'avoir examinée.
   • Si le script n'est pas disponible, comparez manuellement les zones de production/source par rapport aux répertoires de test et aux conventions de nommage de test pour trouver les portions du référentiel non testées ou faiblement testées.
   • Trouvez les tests directs pour le code modifié ou demandé.
   • Trouvez les tests indirects qui couvrent le même comportement via un workflow de niveau supérieur.
   • Inspectez les assertions, les fixtures, les mocks, la configuration, et les noms de test pour voir ce qui est réellement prouvé.
   • Notez les tests obsolètes dont les noms ou les fixtures ne correspondent plus au comportement actuel.

4. Identifiez les lacunes.

   • Routes, fonctionnalités, services, paquets, commandes, jobs, ou limites d'intégration entières sans tests.
   • Tests de chemins critiques manquants.
   • Tests qui ne font que rendre ou appeler du code sans assertions significatives.
   • Tests qui se moquent du comportement qu'ils prétendent couvrir.
   • Tests négatifs/erreur/permission manquants.
   • Tests de limites de tenant/ownership/rôle manquants.
   • Validation, pagination, tri, filtrage, fuseau horaire, race/idempotence, retry, ou tests d'état vide manquants.
   • Test de régression manquant pour un bug corrigé.
   • Tests de contrat manquants pour les changements d'API/schéma/client.
   • Tests de docs/exemples manquants quand les exemples font partie du contrat utilisateur.
   • Tests de migration/rétrocompatibilité manquants quand la forme des données change.

5. Vérifiez en toute sécurité.

   • Exécutez la découverte de tests ciblée ou les tests existants pertinents quand c'est rapide et conventionnel pour le référentiel.
   • Utilisez les commandes de liste de tests, grep/recherche, vérification de type, lint, ou les fichiers de test ciblés selon les besoins.
   • N'installez pas les dépendances, ne démarrez pas de services longue durée, et n'exécutez pas de suites complètes coûteuses sauf si l'utilisateur le demande ou si le référentiel s'y attend clairement.
   • Ne lancez jamais une commande qui écrit dans le référentiel comme effet secondaire. python -m compileall et py_compile émettent des fichiers .pyc, les formateurs réécrivent les sources, et les installateurs modifient les lockfiles. La sortie .pyc est généralement gitignorée, donc git status aura l'air propre alors que l'arborescence a en fait été modifiée. Préférez les vérifications qui n'écrivent rien, et si une langue n'offre pas de vérification en lecture seule, indiquez-le sous les vérifications ignorées.
   • Enregistrez les vérifications exécutées et ignorées.

Rubrique de sévérité

• P0 : Tests manquants pour le code qui peut causer une perte de données, une exposition de sécurité/confidentialité, des erreurs de paiement/facturation, des actions destructrices, ou une panne de production sans filet de sécurité pratique.
• P1 : Couverture manquante à haut impact pour les chemins utilisateur courants, l'auth/autorisation, les contrats d'API critiques, les migrations, les jobs en arrière-plan, ou le comportement bloquant la livraison.
• P2 : Risque de régression significatif autour de cas limites importants, validation, gestion des erreurs, transitions d'état, intégrations, ou tests obsolètes/faibles.
• P3 : Nettoyage de tests de risque inférieur, dérive de nommage, amélioration de fixture, tests redondants, ou polish de couverture utile.

Normes de preuve

• Vérifiez chaque citation avant de l'écrire. Relisez la plage exacte et confirmez qu'elle contient ce que vous décrivez. Quand vous citez un symbole nommé, une fonction, une CTE, ou un bloc, citez la ligne où le nom est défini, pas une ligne à l'intérieur d'un bloc voisin. Quand vous citez du texte, citez le fichier où la citation se trouve réellement. Préférez une seule ligne d'ancrage contenant un jeton distinctif sur une plage comptée à la main.
• Quand vous attribuez une découverte à la sortie d'un outil, citez le chemin et la ligne que l'outil lui-même a rapportés. Ne déduisez jamais les lignes sur lesquelles un linter ou un vérificateur de type a tiré en lisant le code. Si la sortie de l'outil ne nomme pas la ligne, signalez le motif sans prétendre que l'outil l'a signalé.
• Ne restatez jamais un comptage d'un grep, d'un script, ou d'un outil sans la sortie brute devant vous. Si vous ne pouvez pas redériver le nombre, décrivez le motif au lieu de le compter.
• Avant de signaler que quelque chose est absent -- config non documentée, une dépendance inutilisée, un contrôle manquant, une variable que rien ne lit -- vérifiez chaque emplacement plausible, pas seulement le premier. Pour une variable de config cela signifie le README, les fichiers d'exemple env, les manifestes de déploiement, les commentaires, et les appelants transitifs de quel que soit l'helper qui la lit. Pour une dépendance, cela signifie s'il s'agit d'une exigence transitive documentée de quelque chose que vous utilisez réellement. Une affirmation négative d'un seul grep n'est pas une preuve.
• Citez le comportement ou le code modifié et la zone de test existante/manquante.
• Incluez les références de fichier et de ligne chaque fois que possible.
• Expliquez ce que les tests actuels prouvent et ce qu'ils ne prouvent pas.
• Pour les lacunes déduites, incluez Confiance : haute/moyenne/basse.
• Recommandez le plus petit niveau de test fiable qui prouve le comportement.
• Incluez des noms de test suggérés ou des scénarios assez précis pour la mise en œuvre.

Format de rapport

Utilisez cette structure sauf si l'utilisateur demande autre chose :

**Audit de lacunes en tests : <portée>**

Aucun code modifié. J'ai examiné <portée brève>, les tests existants, et les conventions de test du référentiel. <résumé de vérification>. Aucun P0 trouvé / P0s trouvés : <comptage>.

1. **P1 : <titre de lacune>.**
   Lacune : <comportement ou risque non couvert>.
   Couverture actuelle : <ce que les tests existants couvrent ou pourquoi aucun n'a été trouvé>.
   Preuve : code `<chemin>:<ligne>`; tests `<chemin>:<ligne>` ou "aucun test direct trouvé dans <zone>".
   Test suggéré : <niveau de test spécifique, fichier/emplacement, scénario, et assertions clés>.

2. **P2 : <titre de lacune>.**
   Lacune : <couverture manquante ou faible>.
   Couverture actuelle : <ce qui est actuellement prouvé>.
   Preuve : code `<chemin>:<ligne>`; tests `<chemin>:<ligne>`.
   Confiance : <haute/moyenne/basse si déduite>.
   Test suggéré : <recommandation spécifique>.

**Plan de tests suggéré**
- <liste ordonnée de tests concrets à ajouter en premier>

**Zones non testées ou faiblement testées**
- <pour les audits complets du référentiel, listez les routes/fonctionnalités/services/paquets/workflows importants qui manquent de tests appropriés, avec une preuve brève>

**Couverture existante qui vaut la peine d'être conservée**
- <seulement incluez les tests utiles qui protègent déjà le comportement important>

**Surfaces examinées mais non profondément inspectées**
- <Pour les audits complets du référentiel uniquement : surfaces qui ont été inventoriées mais pas inspectées profondément ce passage, et lesquelles relancer ensuite. Omettez cette section entièrement pour les audits ciblés.>

**Vérifications exécutées**
- `<commande>` : <résultat>

**Non testé**
- <suites de tests, services, navigateurs, identifiants, ou lacunes de dépendance et pourquoi>

**Hypothèses**
- <seulement incluez si utile>

Si aucune lacune significative n'est trouvée, dites-le clairement, nommez la couverture la plus forte observée, et listez tout risque résiduel.

Implémentation de tests après audit

Quand l'utilisateur demande d'ajouter des tests :

• Implémentez d'abord les lacunes prioritaires.
• Suivez le style de test existant, les usines, les mocks, les helpers, le nommage, et le placement de fichiers.
• Préférez les tests ciblés qui prouvent le comportement avec des assertions claires.
• Évitez les tests de snapshot larges sauf si les snapshots sont déjà la bonne convention locale.
• Mettez à jour les fixtures, les données de test, ou les exemples de contrat seulement quand nécessaire pour les tests sélectionnés.
• Lancez les nouveaux tests et les tests existants liés les plus proches.
• La réponse finale devrait mapper les lacunes aux tests ajoutés et lister les vérifications exécutées.

Compétences connexes

Cette compétence est l'une des sept compétences de révision qui partagent un contrat de rapport unique : chaque découverte porte une sévérité P0-P3 et un chemin:ligne que vous pouvez ouvrir. Les cinq autres couvrent la préparation de lancement, la sécurité, la structure du référentiel, les idées d'amélioration, et la communication de demande pull. Elles sont à https://github.com/specialone0007/review-skills.

Notes de portabilité d'agent

• Utilisez shell, recherche, git, navigateur, CI, couverture, ou outils MCP disponibles selon les besoins.
• Si l'exécution de tests n'est pas disponible, continuez avec l'inspection de source et de test et indiquez la limitation.
• Si l'hôte supporte les commentaires de révision en ligne, émettez-les seulement pour les lacunes de test confirmées et exploitables et gardez les plages serrées.