Une couverture de code à 100 % est-elle une bonne chose lorsque l'on effectue des tests unitaires ?

Question

J'ai toujours appris que faire une couverture maximale du code avec des tests unitaires est bon . J'entends aussi des développeurs de grandes entreprises comme Microsoft dire qu'ils écrivent plus de lignes de code de test que le code exécutable lui-même.

Maintenant, Est-ce que c'est vraiment génial ? Ne semble-t-il pas parfois perte totale de temps qui n'a d'effet que sur rendre l'entretien plus difficile ?

Par exemple, disons que j'ai une méthode DisplayBooks() qui alimente une liste de livres à partir d'une base de données. Les exigences du produit indiquent que s'il y a plus de cent livres dans le magasin, seule une centaine doit être affichée .

Donc, avec TDD,

1. Je vais commencer par faire un test unitaire BooksLimit() ce qui permettra de sauvegarder deux cents livres dans la base de données, appelez DisplayBooks() et faire un Assert.AreEqual(100, DisplayedBooks.Count) .
2. Puis je testerai si ça échoue,
3. Alors je vais changer DisplayBooks() en fixant la limite des résultats à 100, et
4. Enfin, je vais réexécuter le test pour voir s'il réussit.

Eh bien, n'est-il pas plus facile de passer directement à la troisième étape, et de ne jamais faire BooksLimit() de test unitaire ? Et n'est-il pas plus agile, lorsque les exigences passent de 100 à 200 livres, de ne changer qu'un seul caractère, au lieu de changer les tests, de les exécuter pour vérifier s'ils échouent, de changer le code et d'exécuter à nouveau les tests pour vérifier s'ils réussissent ?

Note : supposons que le code est entièrement documenté. Sinon, certains pourraient dire, et ils auraient raison, que faire des tests unitaires complets aidera à comprendre un code qui manque de documentation. En fait, avoir un BooksLimit() Le test unitaire montrera très clairement qu'il existe un nombre maximum de livres à afficher, et que ce nombre maximum est de 100. Il serait beaucoup plus difficile de pénétrer dans le code qui ne fait pas partie des tests unitaires, car cette limite peut être mise en œuvre par le biais de la méthode suivante for (int bookIndex = 0; bookIndex < 100; ... o foreach ... if (count >= 100) break; .

Answer 1

Désolé pour mon anglais.

Une couverture de code de 100% est un trouble physiologique managérial pour impressionner artificiellement les parties prenantes. Nous faisons des tests parce qu'il y a du code complexe qui peut conduire à des défauts. Nous devons donc nous assurer que le code complexe a un scénario de test, qu'il est testé et que les défauts sont corrigés avant d'être mis en production.

Nous devons viser à tester quelque chose de complexe et non pas n'importe quoi. Maintenant, cette complexité doit être exprimée en termes de nombre métrique qui peut être la complexité cyclomatique, les lignes de code, les agrégations, le couplage, etc. ou probablement la culmination de toutes ces choses. Si nous trouvons cette métrique plus élevée, nous devons nous assurer que cette partie du code est couverte. Ci-dessous mon article qui couvre ce qui est le meilleur % pour la couverture du code.

Une couverture de code à 100% est-elle vraiment nécessaire ?

Answer 2

Premièrement, il est difficile d'obtenir 100 %, surtout sur les grands projets ! Et même si vous y parvenez, lorsqu'un bloc de code est couvert, cela ne signifie pas qu'il fait ce qu'il est censé faire, à moins que vos tests n'affirment toutes les entrées et sorties possibles (ce qui est presque impossible).

Je ne considérerais donc pas qu'un logiciel est bon simplement parce qu'il a une couverture de code de 100%, mais la couverture de code reste une bonne chose à avoir.

N'est-il pas plus simple de passer directement à la troisième étape, et de ne jamais faire de test unitaire de BooksLimit() ?

le fait d'avoir ce test vous donne la certitude que si quelqu'un modifie le code et que le test échoue, vous remarquerez que quelque chose ne va pas dans le nouveau code et vous éviterez ainsi tout bug potentiel dans votre application.

Answer 3

Lorsque le client décide de modifier la limite à 200, bonne chance pour trouver des bogues liés à ce test apparemment trivial. En particulier, lorsque vous avez 100 autres variables dans votre code, et que 5 autres développeurs travaillent sur un code qui repose sur ce minuscule élément d'information.

Ce que je veux dire : s'il a de la valeur pour l'entreprise (ou, si vous n'aimez pas le nom, pour le cœur très important du projet), testez-le. Ne l'écartez que lorsqu'il n'y a pas de moyen possible (ou bon marché) de le tester, comme l'interface utilisateur ou l'interaction avec l'utilisateur, ou lorsque vous êtes sûr que l'impact de ne pas écrire ce test est minime. Ceci est encore plus vrai pour les projets dont les exigences sont vagues ou changent rapidement [comme je l'ai douloureusement découvert].

Pour l'autre exemple que vous présentez, il est recommandé de tester les valeurs limites. Vous pouvez donc limiter vos tests à quatre valeurs seulement : 0, un nombre magique entre 0 et BooksLimit, BooksLimit, et un nombre supérieur.

Et, comme d'autres l'ont dit, faites des tests, mais soyez sûr à 100% que quelque chose d'autre peut échouer.