Développement piloté par les tests - convaincez-moi! [fermé]

Je sais que certaines personnes sont de grands partisans du développement piloté par les tests. J'ai utilisé des tests unitaires dans le passé, mais uniquement pour tester des opérations qui peuvent être testées facilement ou qui, je crois, seront très probablement correctes. La couverture complète ou presque complète du code semble prendre beaucoup de temps.

1. Pour quels projets utilisez-vous le développement piloté par les tests? L'utilisez-vous uniquement pour des projets au-dessus d'une certaine taille?
2. Dois-je l'utiliser ou non? Convainquez-moi!

Ok, quelques avantages pour TDD:

1. Cela signifie que vous vous retrouvez avec plus de tests. Tout le monde aime avoir des tests, mais peu de gens aiment les écrire . L'intégration de l'écriture de test dans votre flux de développement signifie que vous vous retrouvez avec plus de tests.
2. Écrire dans un test vous oblige à réfléchir à la testabilité de votre conception, et une conception testable est presque toujours une meilleure conception. Je ne comprends pas très bien pourquoi cela se produit, mais mon expérience et celle de la plupart des évangélistes TDD semble le confirmer.
3. Voici une étude disant que bien que TDD prenne un peu plus de temps à écrire, il y a un bon retour sur investissement car vous obtenez un code de meilleure qualité, et donc moins de bugs à corriger.
4. Il vous donne confiance dans le refactoring. C'est un grand sentiment de pouvoir changer un système sans se soucier de tout casser car il est assez bien couvert par les tests unitaires.
5. Vous n'obtenez presque jamais un bug de répétition, car tous ceux que vous trouvez devraient subir un test avant d'obtenir un correctif.

Vous avez demandé à être convaincu, il s'agissait donc d'avantages. Voir cette question pour une vue plus équilibrée.

À l'origine, Robert C. Martin a fait ces remarques - je peux les appuyer sur ma propre expérience:

• Vous construirez automatiquement une suite de tests de régression de tests unitaires au fur et à mesure.
• Vous ne passerez presque jamais de temps à déboguer, comme si vous vous codiez dans un trou, il est plus facile d'annuler votre code au point où le dernier test a réussi, plutôt que d'ouvrir un débogueur.
• Toutes les quelques minutes, vous vérifiez que votre code fonctionne - tout (ou au moins tout le comportement couvert par les tests, qui si vous faites TDD est un pourcentage très élevé).

Je fais à peu près tout le temps TDD, que je travaille sur la production ou que je joue du code; J'ai du mal à coder d'une autre manière ces jours-ci.

(Avertissement: je ne fais pratiquement aucun truc d'interface utilisateur, donc je ne peux pas discuter de TDD pour les interfaces utilisateur.)

J'utilise TDD dans à peu près tout ce que je fais, des applications triviales aux piles SIP entières.

Je n'utilise pas TDD dans un site Web PHP hérité que j'ai repris. Je trouve douloureux de ne pas avoir de tests. Et je trouve cela extrêmement ennuyeux de casser accidentellement des parties du site parce que je n'ai pas de suite de tests de régression me disant que j'ai cassé quelque chose. Le client n'a pas le budget pour moi pour (a) écrire des tests pour la base de code et (b) dans le processus rendre le code testable en premier lieu, donc je viens de le supporter.

• Chaque fois que votre client peut être approvisionné plus efficacement (ils seront peut-être bien liés aux tests - et cela réduira au moins la discussion de fin de projet)
• Chaque fois que cela prendrait plus de temps à tenir vos co-développeurs informés sur TOUT dans le code que de faire des efforts pour construire le test - et c'est plus tôt que vous ne le pensez

Quelle? Pas de réponse négative!?

Avis de non-responsabilité: je ne suis pas contre les tests unitaires. Quand les gens disent TDD, je suppose qu'ils veulent dire la version qui ressemble à la maladie où ils écrivent des tests avant d'écrire le code pour 80-100% de tout le code qu'ils écrivent.

Je dirais:

• C'est un catalyseur. Si la capture de problèmes de régression est un problème si énorme pour vous que le TDD entièrement automatique dès le début semble utile, l'écriture de tests pour chaque dernier morceau de code que vous écrivez pourrait vous aider à ignorer le vrai problème.

• Cela aide les gens à ignorer le vrai problème. Lorsque la correction d'un bug se transforme en un jeu de whack-a-mole où deux autres pop-up, l'architecture souffle. Concentrer. Concentrez-vous sur le vrai problème. Voir les taupes avant qu'elles ne soient battues est bien, mais vous ne devriez pas être là en premier lieu.

• Ça mange beaucoup de temps. J'ai rencontré des bugs occasionnels. Je n'en frappe pas tellement qu'il semble intéressant de préfixer chaque nouvelle chose que j'écris avec un test pour cela. Détectez les problèmes où ils sont susceptibles de se produire. Traitez les erreurs de manière à ce qu'elles soient faciles à diagnostiquer. Valider. Testez aux points clés de chevauchement / goulot d'étranglement. Mais pour pleurer à haute voix, ne testez pas tous les derniers getter et setter dans quelque chose qui n'aurait probablement pas dû avoir ceux en premier lieu.

• Objectif de conception: il n'y a absolument aucun moyen, même un bon développeur va écrire le meilleur code possible lorsqu'il se concentre également sur le test. Si cela semble être la seule façon d'avoir un design décent, je recommanderais de voir ce qui précède sur "se concentrer sur le vrai problème".

• Échec de la macro-conception: la base de code de mon travail actuel est truffée d'interfaces qui ne sont jamais utilisées plus d'une fois et de violations massives du principe de base DRY que je n'ai finalement compris que lorsque j'ai réalisé que les gens écrivaient pour les cadres de test et testaient dans général. Les tests ne doivent pas conduire à une architecture stupide. Non vraiment, il n'y a rien qui soit en quelque sorte plus évolutif ou digne de l'entreprise de copier et coller 20 fichiers et de n'apporter des modifications importantes qu'à deux d'entre eux. L'idée est de séparer les préoccupations, pas de les diviser au milieu. L'abstraction inutile et inutile vous coûtera plus que jamais une couverture à 95%.

• C'est vraiment populaire et beaucoup de gens l'aiment vraiment. Si ce n'est pas une raison suffisante pour au moins deviner et / ou examiner la merde de toute technologie avant son adoption, apprenez-vous un peu de paranoïa.