J'ai lu de nombreux articles sur les joies et les avantages des tests unitaires. Existe-t-il un bon argument contre les tests unitaires ?
Dans les endroits où j'ai travaillé auparavant, les tests unitaires sont généralement utilisés comme une raison de travailler avec un département de test plus petit ; la logique est la suivante "Nous avons des tests unitaires ! Notre code ne peut pas échouer ! Parce que nous avons des tests unitaires, nous n'avons pas besoin de vrais testeurs !"
Bien sûr, cette logique est erronée. J'ai vu de nombreux cas où l'on ne peut pas se fier aux tests. J'ai également vu de nombreux cas où les tests sont devenus obsolètes en raison de calendriers serrés - lorsque vous avez une semaine pour faire un travail important, la plupart des développeurs passent la semaine à faire le vrai code et à expédier le produit, plutôt que de remanier les tests unitaires pendant cette première semaine, puis de plaider pour au moins une autre semaine pour faire le vrai code, et enfin de passer une dernière semaine à mettre les tests unitaires à jour avec ce qu'ils ont réellement écrit.
J'ai également vu des cas où la logique métier impliquée dans le test unitaire était plus monstrueuse et difficile à comprendre que la logique enfouie dans l'application. Lorsque ces tests échouent, vous devez passer deux fois plus de temps à essayer de résoudre le problème - le test est-il défectueux, ou le vrai code ?
Les fanatiques ne vont pas aimer ce passage : l'endroit où je travaille a largement échappé à l'utilisation des tests unitaires parce que les développeurs sont d'un calibre suffisamment élevé pour qu'il soit difficile de justifier le temps et les ressources nécessaires à l'écriture de tests unitaires (sans compter que nous utilisons de VRAIS testeurs). Pour de vrai. L'écriture de tests unitaires ne nous aurait apporté qu'une valeur minimale, et le retour sur investissement n'est tout simplement pas là. Bien sûr, cela donnerait aux gens un sentiment de chaleur et de confort "Je peux dormir la nuit parce que mon code est PROTÉGÉ par des tests unitaires et que, par conséquent, l'univers est dans un bel équilibre". Mais la réalité est que notre métier est d'écrire des logiciels, pas de donner aux managers des sentiments chaleureux et flous.
Bien sûr, il y a absolument de bonnes raisons d'avoir des tests unitaires. Le problème avec les tests unitaires et le TDD est le suivant :
En réalité, il devrait être utilisé comme un des outils ou des méthodologies que vous utilisez au quotidien, et il ne doit jamais devenir le site une méthodologie unique.
Les vrais testeurs sont excellents, mais beaucoup d'entreprises n'en ont pas. Elles font appel à des personnes prises au hasard dans la rue pour tester l'application.
À l'inverse, j'ai vu toutes ces mêmes raisons utilisées comme une excuse à la paresse. "Nous avons de vrais testeurs, pourquoi devrais-je prendre la peine d'écrire des tests pour mon code ?" Les tests unitaires automatisés ne remplacent pas l'AQ mais ils soulagent les testeurs AQ des tests de régression fastidieux afin qu'ils puissent se concentrer sur la recherche de nouveaux bugs. Les tests unitaires sont comme une comptabilité en partie double. Ils sont peut-être un peu plus longs à écrire, mais ils permettent de détecter les erreurs au moment où elles se produisent, plutôt que des jours, des semaines ou des années plus tard.
@code, je suis d'accord. J'ai apprécié la chance d'avoir un bon grognement sur les tests unitaires parce que je les ai vus mal utilisés trop souvent ou mal mis en valeur. Cependant, je ne pense pas qu'ils doivent remplacer ou diminuer les tests de régression, mais c'est un tout autre débat.
Je ne suis pas d'accord. Coder avec des tests unitaires va plus vite que coder sans tests unitaires. L'effet net est un développement plus rapide même si vous devez écrire du code pour les tests unitaires. Si l'effet net est plus lent, vous devriez peut-être vous efforcer de faire du TDD (test first).
@duffymo : bien, c'est en quelque sorte vrai, mais les zélateurs des tests répliqueront en disant que le coût est plus que compensé en aval par une confiance et une fiabilité améliorées lors des changements.
Au départ, cependant, avant que votre équipe n'ait jamais effectué de tests unitaires, il faudra plus de temps pour écrire votre code. Une fois que vous aurez surmonté l'obstacle initial que représente le fait d'écrire d'abord quelques tests, vous verrez le bénéfice en termes de productivité et, par conséquent, le bénéfice en termes de temps.
Pratiquement aucun de mes bogues n'aurait été trouvé par des tests unitaires. Mes bogues sont principalement des bogues d'intégration ou des bogues de cas d'utilisation inattendus, et pour les trouver plus tôt, des tests système plus étendus (et idéalement automatisés) auraient été le meilleur pari.
J'attends des arguments plus factuels et moins religieux en faveur des tests unitaires, comme l'a dit dummymo. Et je ne parle pas d'une expérience dans un cadre académique ; je parle d'un argument qui pour mon scénario de développement et capacité de programmation, le rapport coût-bénéfice serait positif.
Donc, pour être d'accord avec les autres réponses à l'OP : parce qu'ils coûtent du temps et que le rapport coût-bénéfice n'est pas démontré.
D'après mon expérience concrète, les tests unitaires sont utiles pour 1) énoncer explicitement les cas d'utilisation qui doivent réussir - ce qui est bon pour la documentation et la démonstration. ce que une fonctionnalité (et non pas comment) 2) la détection des bogues - principalement des bogues de conception, car vous commencez par l'interface et travaillez vers le bas et 3) les tests de régression. Vous pouvez travailler en toute impunité en sachant que votre suite de tests vous alertera si vous avez cassé quelque chose. Ces trois éléments, toujours selon mon expérience, justifient amplement le coût.
Je ne nie pas que les tests unitaires puissent fournir tous ces avantages. Mais je pense que les tests système fournissent les mêmes avantages presque exactement, plus la capture de beaucoup de bogues que les tests unitaires manqueront. De plus, les tests système nécessitent moins de réécriture lors du remaniement, car si le comportement externe ne change pas, les tests système restent valides, mais les tests unitaires pour les classes remaniées doivent être remplacés.
Je parie que la plupart des personnes qui votent ce texte veulent une excuse pour être paresseux ; cependant, je pense qu'il a raison le plus souvent.
Vérification formelle.
Si vous pouvez prouver formellement l'exactitude du code, il n'y a aucune raison de le tester unitairement, à moins que la condition de test n'apporte de nouvelles variables, auquel cas, vous n'auriez toujours qu'un petit nombre de tests unitaires (ou de preuves pour les nouvelles variables).
@Ben : "largement ouvert à l'interprétation" ? Je ne comprends pas. Si vous pouvez prouver formellement l'exactitude du code, il n'y a aucune raison de le tester unitairement, sauf si la condition de test apporte de nouvelles variables, auquel cas, vous n'auriez toujours qu'une petite quantité de tests unitaires.
Sauf pour les cas triviaux, même si vous pouvez (êtes capable de) prouver formellement quelque chose, vous allez probablement tout gâcher c'est pourquoi nous testons tout : thedailywtf.com/Comments/The-Proven-Fix.aspx . Tout comme moi peut tirer un ballon de basket dans un but, mais ça ne veut pas dire que je sera juste en essayant je me plante au hasard.
Si j'ai une fonction f : X -> Y Comment puis-je tester ce qui se passe quand je l'applique à une valeur ? z de Z ? Non. Parce que je ne peux pas appliquer f a z ce qui est par définition. Et ce n'est pas mon travail d'écrire des tests pour l'implémentation du langage. Les preuves reposent sur des hypothèses. Tout comme les tests unitaires (bien que, beaucoup plus hypothèses). De toute façon, les tests unitaires ne fonctionnent pas dans les langages courants parce que le statu quo inclut de manière omniprésente l'utilisation d'états mutables accessibles globalement, la dépendance à la plate-forme et la violation de l'encapsulation. Cela dit, je fais des tests unitaires, mais pas autant que nécessaire dans les langages dynamiques.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
2 votes
Ver programmeurs.stackexchange.com/questions/66480/