Test Audit
Cette compétence a deux modes :
- Création. Le portail de création ci-dessous s'applique à chaque test que vous ajoutez ou modifiez.
- Audit. Supprimez les preuves de faible valeur par lots cohérents, regroupés par responsable de production. Ne recherchez jamais un nombre de suppressions ; l'objectif est une suite où chaque contrat a un seul responsable fort, pas un nombre plus petit.
Pour une campagne qui élimine toute la surface de test d'un sous-système en une seule fois, lisez d'abord CAMPAIGN.md.
Portail de création
Avant d'ajouter un test, répondez à ces quatre questions :
- Quel comportement observable, invariant ou contrat indépendant protège-t-il ?
- Quelle régression crédible le ferait échouer ?
- Pourquoi la preuve existante ne le couvre-t-elle pas ? Chaque contrat devrait avoir un propriétaire principal à la frontière la plus solide. Un test à une autre couche nécessite un risque de transport ou de cycle de vie distinct pour le justifier. Étendez les tables existantes et les fixtures partagées plutôt que d'ajouter des quasi-copies, et consolidez les configurations répétées.
- A-t-il besoin d'une exportation, d'un indicateur, d'un wrapper ou d'un crochet d'injection qui n'a aucun appelant en production ? Si oui, déplacez plutôt la preuve vers la frontière réelle.
Règles de support :
- Utilisez le guide des coûts et des limites pour choisir où le test se trouve et ce qu'il peut coûter.
- Un test de régression doit échouer avant le correctif pour la raison prévue et réussir après la réparation. Si vous ne pouvez pas montrer l'échec avant le correctif, dites-le dans votre rapport.
- Une seule régression à la frontière propriétaire couvre un bogue. Ne la rejouez jamais à chaque couche que le bogue a traversée.
- Un refactoring préservant le comportement ne doit pas casser le test.
Motifs indésirables
- Rejetez les auto-comparaisons, les inventaires copiés, les recherches dans le code source, les assertions sur l'implémentation ou la forme des appels, les contrats en double, les coutures uniquement pour les tests, les valeurs attendues générées par le sujet testé, et les mocks qui fournissent le comportement testé.
- Les fixtures ne doivent pas fabriquer de reçus ou d'ordres que le propriétaire devrait produire, et ne doivent pas prétendre à une persistance via un chemin que le code n'écrit jamais.
- Un contrôle négatif doit échouer au niveau de la garde prévue, et le nom d'un test doit correspondre au comportement qu'il exerce réellement.
- Lors de l'audit de candidats, utilisez la liste complète.
Barre de rétention
- Conservez les tests qui protègent des contrats indépendants : API publique, SDK, protocole, configuration, migration, stockage, sécurité, plateforme, valeurs par défaut, octets de prompt, sortie générée dans plusieurs langues, packaging, publication, architecture et ordre observable. Le fait d'être statique ou lent ne rend pas un test jetable.
- L'inspection du code source n'est acceptable que lorsqu'elle survit à des refactorings qui ne modifient que les identifiants et protège un contrat indépendant orienté utilisateur.
- Un test de base qui échoue peut être un bogue produit à réparer, pas un test à supprimer.
Audit et validation
- Avant toute modification d'audit, lisez les preuves candidates et le flux de travail. Inspectez l'ensemble des propriétaires, des appelants et de l'historique, et enregistrez les preuves qui restent avant de supprimer quoi que ce soit.
- Supprimez les coutures de production obsolètes avec leurs tests. N'optimisez jamais le nombre de suppressions.
- Ne modifiez pas la copie de travail (checkout) pendant qu'une exécution de test est en cours. Exécutez la commande de test ciblée du projet pour le propriétaire et les tests frères, exécutez les vérifications des fichiers modifiés du projet, puis obtenez une révision avant de valider.
- Rapportez les causes, les contrats conservés, la preuve et son coût, les lignes de code modifiées en production par rapport aux tests, et les actions de suivi. Validez, poussez ou publiez uniquement lorsque la tâche vous en donne l'autorité.