Y a-t-il des domaines où TDD offre un retour sur investissement élevé et d'autres domaines où le retour sur investissement est si faible qu'il ne vaut pas la peine d'être suivi? [fermé]

Développement piloté par les tests. Je comprends, j'aime ça.

Mais l'écriture de tests nécessite des frais généraux. Donc, TDD devrait être utilisé universellement dans toute la base de code, ou y a-t-il des domaines où TDD fournit un retour sur investissement élevé et d'autres domaines où le retour sur investissement est si faible qu'il ne vaut pas la peine d'être suivi.

Je dirais d'éviter le TDD dans les endroits où le code est susceptible de changer beaucoup de structure. C'est à dire, c'est génial d'avoir une pile de tests pour une méthode dont la signature change rarement mais qui est refactorisée en interne plus fréquemment, mais ça craint d'avoir à corriger vos tests chaque fois qu'une interface très volatile change de façon spectaculaire.

Les applications sur lesquelles j'ai travaillé récemment étaient des applications Web basées sur les données, construites sur une architecture basée sur Gui-> Presenter-> BusinessLogic-> Data Access Layer. Ma couche d'accès aux données est testée comme l'entreprise de personne. La couche logique métier est assez bien testée. Les Presenters ne sont testés que dans les zones les plus stables, et l'interface graphique, qui change toutes les heures, n'a presque pas de tests.

Je suggère d'écrire une suite de tests complète dans les domaines où il est judicieux et pratique de le faire. Dans les domaines moins pratiques, rédigez des tests de santé mentale.

D'après mon expérience, les frais généraux d'un ensemble complet de cas de test en valent certainement la peine dans la plupart des cas, mais en réalité, la couverture du code a des rendements décroissants. À un moment donné, écrire plus de tests juste pour augmenter la couverture du code n'a tout simplement aucun sens.

Par exemple, selon votre langue / technologie, tester l'interface utilisateur peut ne pas être pratique ni même réalisable. De nombreux tests reposeront probablement sur ce que voit un utilisateur et ne peuvent pas être automatisés. Comment testeriez-vous qu'une méthode pour générer un captcha produise une image lisible par un humain par exemple?

Si un ensemble complet de tests va vous prendre trois jours pour écrire, la probabilité qu'un bug soit introduit dans ce composant sur la piste est très faible, et la fonction elle-même ne prend qu'une demi-heure à écrire, vous devriez probablement réfléchir sérieusement pour savoir si ce temps en vaut la peine. Peut-être que le simple fait d’écrire un test de santé mentale de base pour cette fonction apporterait une valeur?

Mon conseil général serait que vous testiez entièrement les composants là où les tests peuvent être écrits assez facilement. Cependant, s'il s'agit d'une zone très difficile à tester, tracez une ligne dans le sable et écrivez des tests qui testeront la zone à un niveau supérieur plutôt que de la tester complètement.

Dans l'exemple de captcha précédent, écrivez peut-être des tests qui vérifient qu'une image de la bonne taille et du bon format est renvoyée et qu'aucune exception n'est levée. Cela vous donne un certain niveau d'assurance sans aller trop loin.

Pour moi, TDD n'est pas une surcharge. C'est juste la façon dont j'écris du code. Pourquoi dites-vous que le test d'écriture est «aérien»? Cela fait simplement partie du processus. Mon point de vue est que le débogage est une surcharge, et c'est une activité que j'ai essentiellement cessé de faire lorsque j'ai commencé le TDD-ing. Avant TDD, le débogage faisait partie intégrante de mon processus d'écriture de logiciels.

Je pense que renoncer au débogage pour l'écriture de test est une très bonne affaire.

Un endroit où TDD craint vraiment est lors du test de vues dans une application MVC.

Étant donné que vous testez une fonction qui renvoie une chaîne html fat, vous êtes bloqué lors de l'analyse html juste pour voir si les choses ont fonctionné. De plus, cela peut devenir un cauchemar de maintenabilité. Un jour, vous déplacez une case à cocher et kaboom, votre test est cassé.

J'aime TDD pour beaucoup de mes tests, mais ce n'est pas le seul outil dans une ceinture de programmeurs.