Couverture de code

La couverture de code mesure la part du code exécutée par une campagne de tests. Un outil instrumente le code (JaCoCo pour Java, Istanbul/nyc ou la couverture V8 pour JavaScript, coverage.py pour Python), exécute les tests et indique quelles lignes et quelles branches ont été atteintes. C’est une métrique boîte blanche, le plus souvent collectée pour les tests unitaires et d’intégration.

Types de couverture

Prenons :

int shippingCost(double total, boolean isMember) {
    if (total >= 100 || isMember) {
        return 0;
    }
    return 5;
}

• Couverture des instructions (lignes) : les deux instructions return ont-elles été exécutées ? Deux tests, (150, false) et (20, false), donnent 100 %.
• Couverture des branches (décisions) : le if a-t-il été à la fois vrai et faux ? Les deux mêmes tests donnent aussi 100 %.
• Couverture des conditions : chaque sous-condition booléenne a-t-elle été évaluée à vrai et à faux ? Les tests ci-dessus n’ont jamais rendu isMember vrai, la couverture n’est donc pas complète. Ajouter (20, true) corrige cela.
• Couverture des fonctions : chaque fonction a-t-elle été appelée au moins une fois ?

La couverture des branches est en général un objectif plus utile que la couverture des lignes, car une seule ligne peut cacher plusieurs chemins.

Ce que la couverture ne vous dit pas

La couverture prouve que le code a été exécuté, pas qu’il a été vérifié. Ce test donne 100 % de couverture des lignes et des branches de la méthode ci-dessus et ne vérifie rien du tout :

@Test
void runsShippingCost() {
    shippingCost(150, false);
    shippingCost(20, false);
}

La couverture ne peut pas non plus révéler du code manquant. Si l’exigence prévoit que les membres d’une certaine région paient la livraison et que personne ne l’a implémenté, il n’y a aucune ligne à signaler comme non couverte. Le mutation testing est la méthode habituelle pour mesurer si les tests détectent réellement les défauts.

Bien l’utiliser

• Regardez les lignes non couvertes, pas seulement le chiffre. Un gestionnaire d’erreur non testé sur le parcours de paiement compte davantage qu’un toString() non testé.
• Appliquez un seuil sur la couverture du code modifié, par exemple « le nouveau code doit avoir au moins 80 % de couverture des branches », plutôt qu’un pourcentage global qui pousse à tester des getters triviaux.
• Ne visez jamais 100 % comme objectif. Quand une métrique devient une cible, des tests sans assertion apparaissent.