Les pièges de la couverture du code

Question

Je cherche des exemples concrets de certains effets secondaires négatifs de la couverture du code.

J'ai remarqué que cela se produisait récemment au travail en raison d'une politique visant à atteindre une couverture de code de 100%. La qualité du code s'est améliorée, c'est certain, mais à l'inverse, les testeurs semblent écrire des plans de test plus laxistes parce que "le code est entièrement testé en unités". En conséquence, certains bogues logiques ont réussi à se glisser dans le code. Ils ont été un TRÈS GRAND PLAISIR à déboguer parce que "le code est entièrement testé en unité".

Je pense que c'était en partie parce que notre outil ne couvrait que les déclarations. Néanmoins, le temps aurait pu être mieux utilisé.

Si quelqu'un a d'autres effets secondaires négatifs d'une politique de couverture de code, veuillez les partager. J'aimerais savoir quel genre d'autres "problèmes" se produisent dans le monde réel.

Merci d'avance.

EDIT : Merci pour toutes les très bonnes réponses. Il y en a quelques-unes que je marquerais comme réponse mais je ne peux en marquer qu'une seule malheureusement.

Answer 1

En une phrase : La couverture de code vous dit ce que vous avez définitivement n'ont pas testé, pas ce que vous ont.

Une partie de la construction d'une suite de tests unitaires de qualité consiste à trouver le code le plus important et le plus risqué et à lui poser des questions difficiles. Vous voulez vous assurer que les éléments difficiles fonctionnent en priorité. Les chiffres de couverture n'ont aucune notion de l'"importance" du code, ni de la qualité des tests.

D'après mon expérience, la plupart des tests les plus importants que vous écrirez sont ceux qui n'ajoutent pratiquement rien à la couverture (des cas limites qui ajoutent quelques pourcentages ici et là, mais qui trouvent des tas de bogues).

Le problème de la fixation d'objectifs de couverture stricts et (potentiellement contre-productifs) est que les développeurs peuvent être amenés à se plier en quatre pour tester leur code. Il y a rendre le code testable, et il y a la torture. Si vous atteignez une couverture de 100 % avec d'excellents tests, c'est fantastique, mais dans la plupart des cas, l'effort supplémentaire n'en vaut pas la peine.

En outre, les gens commencent à être obsédés par les chiffres plutôt que de se concentrer sur la qualité des tests. J'ai vu des tests mal écrits qui avaient une couverture de 90+%, tout comme j'ai vu d'excellents tests qui n'avaient qu'une couverture de 60-70%.

Encore une fois, j'ai tendance à considérer la couverture comme un indicateur de ce qui est définitivement n'a pas a été testé.

Answer 2

D'après mon expérience, le plus gros problème avec les outils de couverture de code est le risque que quelqu'un soit victime de la croyance que "une couverture de code élevée" équivaut à "de bons tests". La plupart des outils de couverture n'offrent que des mesures de couverture des énoncés, par opposition à la couverture des conditions, des chemins de données ou des décisions. Cela signifie qu'il est possible d'obtenir une couverture de 100% sur un bout de code comme celui-ci :

for (int i = 0; i < MAX_RETRIES; ++i) {
    if (someFunction() == MAGIC_NUMBER) {
        break;
    }
}

... sans jamais tester la condition de terminaison de la boucle for.

Pire encore, il est possible d'obtenir une "couverture" très élevée à partir d'un test qui invoque simplement votre application, sans prendre la peine de valider la sortie, ou en la validant incorrectement.

C'est simple, faible niveaux de couverture du code est certainement une indication de l'insuffisance des tests, mais haut les niveaux de couverture sont pas une indication d'un test suffisant ou correct.

Answer 3

Ce n'est pas parce qu'il y a une couverture de code que vous testez réellement tous les chemins de la fonction.

Par exemple, ce code a quatre chemins :

if (A) { ... } else { ... }
if (B) { ... } else { ... }

Cependant, deux tests seulement (par exemple, un avec A et B vrai, un avec A et B faux) donneraient une "couverture de code de 100%".

C'est un problème car la tendance est d'arrêter les tests une fois que vous avez atteint le chiffre magique de 100%.

Answer 4

Parfois, les cas particuliers sont si rares qu'ils ne valent pas la peine d'être testés, mais une règle stricte de couverture du code exige que vous les testiez quand même.

Par exemple, en Java, l'algorithme MD5 est intégré, mais il est techniquement possible qu'une exception de type "algorithme non pris en charge" soit levée. Elle n'est jamais levée et votre test devrait passer par d'importantes girations pour tester ce chemin.

Ce serait beaucoup de travail gâché.

Answer 5

À mon avis, le plus grand danger que court une équipe en mesurant la couverture du code est qu'elle récompense les gros tests et pénalise les petits. Si vous avez le choix entre écrire un seul test qui couvre une grande partie des fonctionnalités de votre application, et écrire dix petits tests qui testent une seule méthode, la mesure de la couverture du code implique que vous devriez écrire le grand test.

Cependant, l'écriture d'un ensemble de 10 petits tests vous donnera des tests beaucoup moins fragiles, et testera votre application de manière beaucoup plus approfondie que ne le fera un seul grand test. Ainsi, en mesurant la couverture du code, en particulier dans une organisation dont les habitudes de test évoluent encore, vous pouvez souvent mettre en place les mauvaises incitations.