Exécuter des tests de mutation sans se noyer dans les survivants

Objectif

Utiliser les tests de mutation comme une vérification de routine que les tests détectent bien les défauts, sans en faire un goulot d'étranglement en intégration continue ni un rapport rempli de survivants auxquels personne ne donne suite. La question de savoir si le score prédit les défauts échappés fait l'objet d'une entrée d'hypothèse séparée ; ceci est la procédure opérationnelle.

Prérequis

Une suite de tests unitaires déterministe et indépendante de l'ordre ; un outil de mutation pour le langage (PIT pour la JVM, StrykerJS pour JavaScript et TypeScript, mutmut pour Python, cargo-mutants pour Rust) ; une couverture de lignes déjà mesurée, puisque le code non couvert ne produit que des mutants « sans couverture ».

Étapes

1. Exécuter l'outil sur un seul module contenant de la logique, pas sur toute la base de code, et lire le rapport. La documentation de PIT liste les résultats par mutant : tué, survivant, sans couverture, expiré, plus les états non viable et erreur. La page de métriques de Stryker définit le score de mutation comme détectés divisé par mutants valides, où détectés compte les mutants tués et expirés.
2. Ouvrir chaque survivant dans le code. Il s'agit de l'une de trois choses : une assertion manquante (le test a exécuté la ligne mais n'a rien vérifié qui en dépende), un cas manquant (une limite qu'aucun test n'atteint), ou un mutant équivalent qui ne peut pas changer le comportement observable, ce que la documentation de PIT illustre avec >= 1 face à > 1 lorsque la valeur vaut toujours 2.
3. Corriger les deux premiers types en renforçant les tests. Pour les équivalents, exclure le mutateur ou annoter la ligne selon ce que permet l'outil, plutôt que d'écrire des tests artificiels.
4. Borner le temps d'exécution : limiter l'exécution aux fichiers modifiés ou utiliser le mode incrémental (--incremental de StrykerJS réutilise les résultats pour les mutants dont les tests couvrants n'ont pas changé) ; fixer un délai d'expiration par mutant ; désactiver les mutateurs qui ne génèrent que du bruit pour la base de code (PIT ignore par défaut les lignes contenant des appels aux frameworks de journalisation courants).
5. Placer l'exécution bornée en intégration continue sur le diff, et une exécution complète selon une planification, avec le rapport publié mais non bloquant.
6. Suivre le score par module et l'utiliser comme un cliquet (« pas plus bas que la dernière exécution ») plutôt que comme un objectif global fixe.

Résultat attendu

Chaque modification produit une courte liste d'assertions manquantes concrètes avant la revue, et le score des modules qui comptent progresse lentement plutôt que de faire l'objet de discussions.

Limites et base de vérification

Le temps d'exécution se multiplie avec le nombre de mutants, et des tests instables ou dépendants de l'ordre rendent les résultats dénués de sens. Les scores ne sont pas comparables d'un outil ou d'un jeu de mutateurs à l'autre. Un score élevé sur du code trivial n'apprend pas grand-chose ; l'effort doit porter sur les modules à logique de branchement. Aucune mesure n'est revendiquée.