La mesure du code parcouru lors des tests est une métrique insuffisante. Tout au plus un indice permettant de se faire une idée de la situation.
Une "vraie" métrique de couverture de code est de mesurer la couverture du code réellement testé par les tests :
Sur phpunit par exemple, ça se fait en utilisant @Covers, qui permet de spécifier la/les fonctions ciblées par le test - et considérer tout autre code comme non parcouru, qu'il le soit réellement ou non.
Je n'ai pas trouvé d'équivalent avec JUnit.
On se retrouve alors avec une mesure du code réellement testé, et pas seulement parcouru.
Et du coup en combinant avec deux autres métriques on a une mesure "maximale" de la qualité du code :
* % de fonctionnalités souhaitées (métier et techniques) faisant l'office de tests -- obtenu via traçabilité des specs et des tests
* % de tests OK <=> % de fonctionnalités réellement opérationnelles
-- là on devrait raisonnablement toujours viser les 100%)
* % de code ciblé par les tests
=> et là on peut viser les 100%. Un score < 100% signifie présence de code superflu et donc surcout inutile de maintenance et donc à supprimer.
@AxS Il me semble que le vrai propos de l'article concerne surtout la qualité de cette couverture, qu'aucun indice ne mesure correctement. L'exemple le plus bateau est:
public function math(float $x): float { return 1 / ($x - 1); }
La couverture est de 100% dès que cette fonction est testée avec $x = 0, mais tous les comportements ne sont pas testés, dont le comportement le plus "intéressant" (bugprone).
La mesure du code parcouru lors des tests est une métrique insuffisante. Tout au plus un indice permettant de se faire une idée de la situation.
Une "vraie" métrique de couverture de code est de mesurer la couverture du code réellement testé par les tests :
Sur phpunit par exemple, ça se fait en utilisant @Covers, qui permet de spécifier la/les fonctions ciblées par le test - et considérer tout autre code comme non parcouru, qu'il le soit réellement ou non.
Je n'ai pas trouvé d'équivalent avec JUnit.
On se retrouve alors avec une mesure du code réellement testé, et pas seulement parcouru.
Et du coup en combinant avec deux autres métriques on a une mesure "maximale" de la qualité du code :
Il y a plus de 5 ans* % de fonctionnalités souhaitées (métier et techniques) faisant l'office de tests -- obtenu via traçabilité des specs et des tests
* % de tests OK <=> % de fonctionnalités réellement opérationnelles
-- là on devrait raisonnablement toujours viser les 100%)
* % de code ciblé par les tests
=> et là on peut viser les 100%. Un score < 100% signifie présence de code superflu et donc surcout inutile de maintenance et donc à supprimer.
@AxS Il me semble que le vrai propos de l'article concerne surtout la qualité de cette couverture, qu'aucun indice ne mesure correctement. L'exemple le plus bateau est:
public function math(float $x): float { return 1 / ($x - 1); }
La couverture est de 100% dès que cette fonction est testée avec $x = 0, mais tous les comportements ne sont pas testés, dont le comportement le plus "intéressant" (bugprone).
Il y a plus de 5 ans