Pourquoi est agile tout sur le développement piloté par les tests (TDD) et non le test piloté par le développement (DDT)?
Je suis donc nouveau dans l'agilité, mais pas développement piloté par les tests . Mes professeurs à l'université étaient tous sur l'idée de tests puis de code puis de tests. Je ne suis pas sûr de comprendre pourquoi. De mon point de vue, c'est beaucoup de coûts initiaux qui seront très probablement modifiés à mesure que votre code évolue.
C'est ainsi que j'imagine TDD et pourquoi cela me confond. Si je devais construire une maison en tant qu'entrepreneur TDD.
Donnez-moi toutes vos spécifications (histoires).
Obtenez l'approbation sur les spécifications.
Décomposer toutes les spécifications en inspection, je pense que j'aurai besoin (voir dans le futur).
Appelez un inspecteur pour examiner ces points et dites-moi que je ne réussis pas l'inspection (merci).
Commencez à construire la maison.
Rappelez l'inspecteur tous les jours (en passant 2/100).
Oh shoot, il y avait un problème avec ma compréhension et maintenant je dois ajouter 9 inspections supplémentaires et en changer 27.
Appelez l'inspecteur en passant 1/109.
Bon sang. Pourquoi l'inspecteur n'aime pas celui-ci ... oh j'ai mis à jour le nom de cette méthode ...
Construisez-en plus.
UGGGGHHHH PLUS DE CHANGEMENTS permettez-moi de mettre à jour le fichu inspecteur. Oh j'échoue pas s ** t.
Ai-je encore fini?
D'accord, cela peut être bizarre, mais je ne vois pas comment je devrais connaître toutes mes méthodes et comment les choses fonctionneront jusqu'à ce que mon code soit là. 99% du temps, je dois revenir en arrière et mettre à jour un test unitaire de toute façon et en ajouter d'autres au fur et à mesure. Cela semble juste à l'envers.
Ce qui semble plus approprié, c'est le DDT ou les tests axés sur le développement, ce que la communauté a presque oublié, semble-t-il.
D'après ma compréhension, le DDT pour une maison ressemblerait à:
Donnez-moi toutes vos spécifications (histoires).
Obtenez l'approbation des spécifications et divisez-les.
Démarrez une unité (la fondation).
Prenez des notes (commentaires) d'une logique délicate.
À la fin avant de commencer l'unité suivante, faites l'inspection (créez un test).
Corrigez tout problème détecté et inspectez-le à nouveau.
Approuvé que cette unité passe à la suivante.
Si nous sommes tous honnêtes, cela ne semble-t-il pas plus humain et centré sur le développeur et l'entreprise? Il semble que les modifications puissent être apportées plus rapidement et sans le surcoût TDD semble créer.
L'un des avantages d'une approche TDD n'est réalisé que lorsque vous effectuez également une conception émergente.
Donc, dans votre première analogie, vous n'écririez pas 100 tests, car il n'y a aucun moyen de savoir à quoi ressemblera votre logiciel.
Vous écrivez un test. Vous l'exécutez. Il échoue. Vous écrivez la plus petite unité de code pour réussir votre test. Ensuite, vous relancez votre test. Ça passe.
Maintenant, écrivez le test suivant, en répétant le processus ci-dessus.
Cela peut sembler une approche inutile au tout début, quand il est évident que votre code est censé faire, mais la grande chose avec cette approche est que votre couverture de test est toujours élevée, et la conception du code est plus propre de cette façon.
En tant que méthode, cela va de pair avec la programmation par paires; une paire écrit le test, la suivante écrit le code pour le faire passer, puis écrit le prochain test, etc.
J'utilise même cette approche lors de l'écriture d'une nouvelle classe; le premier test est un appel pour lancer le constructeur de classe. Mais je n'ai pas encore écrit le cours, donc ça échoue. Ensuite, j'écris la classe simple et vide, et mon premier test réussit.
Une fois que vous êtes dans l'état d'esprit, il est très difficile de ne pas y être et de coder à l'ancienne.
Je recommanderais de travailler dans un bon environnement Agile pour apprendre cela, ou de lire quelques bons livres Agile (Clean Code et Clean Coder sont tous les deux très bons) pour mieux comprendre.
Le logiciel n'est pas une maison. L'intuition est bonne, mais comprenez qu'elle n'est pas toujours correcte.
Décomposer toutes les spécifications en inspection, je pense que j'aurai besoin (voir dans le futur).
Ce n'est pas exact. Dans TDD, vous décrivez comment vous souhaitez utiliser le code. Les spécifications disent "Il doit y avoir une maison, avec un moyen d'y entrer." Le test dit ensuite "Hé, je veux avoir une porte d'entrée, avec un bouton." C'est loin moins voir dans l'avenir que de commencer par la mise en œuvre de la construction d'un cadre de porte, d'un bouton, d'un verrou, etc. (ou du moins l'argument va-t-il).
Rappelez l'inspecteur tous les jours (en passant 2/100).
Ce n'est pas correct. Vous n'écrivez pas de tests pour la maison. Vous écrivez des tests pour le cadre de la porte d'entrée, puis vous les rendez verts. Teste ensuite la solidité de la porte, la rendant verte. Vous devriez avoir peut-être une douzaine de tests au plus cassés à un moment donné. Habituellement, c'est plus près de deux à quatre.
De plus, l'analogie "appeler l'inspecteur" implique qu'il faut un certain temps à la personne pour sortir et faire son travail. L'exécution de tests unitaires pour une itération TDD devrait littéralement prendre quelques secondes.
Il semble que les modifications puissent être apportées plus rapidement et sans que la surcharge TDD semble créer.
Les frais généraux sont inférieurs à ce que vous semblez sous-entendre. Quelques secondes pour exécuter les tests, peut-être une demi-douzaine de fois, sont sans conséquence sur le temps de développement global.
Le problème du développement en premier est parfois lorsque vous arrivez au test, vous découvrez qu'il y a un gros problème . Comme si vous aviez mis le lit à côté des toilettes et que personne ne voulait y vivre, une sorte de problème. Choses qui prennent plus de temps à réparer que toute sorte de frais généraux TDD. Des choses que TDD aurait pu attraper, car TDD vous oblige à utiliser votre code dès le départ et à réfléchir à la manière de vous interfacer avec lui.
Mes professeurs à l'université étaient tous sur l'idée des tests puis du code puis du test.
Cela dit, TDD n'est pas omniprésent. De nombreux endroits font encore du développement en premier et une grande partie des prétendus avantages du TDD sont exagérés. Ce qui est important, c'est de faire les tests et de les rendre bons. L'ordre dans lequel vous effectuez le travail est moins important.
Les similitudes entre la construction d'une chose physique et l'écriture d'un logiciel sont assez minimes.
Cela dit, il y a une énorme distinction à souligner:
Il y a une différence entre "créer un test" et "exécuter un test".
Dans l'exemple de la construction d'une maison, les exigences et les tests précèdent la construction physique. Et des parties de la suite de tests sont exécutées en continu - par plusieurs agents même! Lorsque le constructeur prend un 2x4, il "teste" immédiatement et automatiquement l'unité par rapport à sa notion de "à quoi ressemble un son 2x4". Il ne crée pas d'exigences après l'avoir récupéré; il y effectue des vérifications préexistantes.
De même pour un mur assemblé, un coffret électrique, la plomberie, etc. - les tests/exigences existent déjà; ils sont gérés implicitement et automatiquement par les yeux entraînés de tout le monde au travail en continu . Une autre suite de tests préexistants est exécutée lors de la visite de l'inspecteur. Si les unités n'ont pas été construites pour passer le test préexistant , elles échouent.
Et de même pour la structure dans son ensemble. Les plans préexistent au buildout. À chaque étape du processus, les ingénieurs travaillent vers un ensemble préexistant de conditions contre lesquelles la structure sera finalement testée lorsque la construction sera terminée. .
Cela dit, tous les projets physiques n'ont pas besoin d'être précédés d'une énorme suite de tests. Si vous allez dans votre atelier et commencez à assembler du bois pour un coffre à jouets ou quelque chose, laissant votre intuition et votre créativité vous guider, ce n'est pas un travail du bois TDD rigoureux. Dans ce cas, vous vous basez essentiellement sur les lois physiques du support et vos attentes approximatives pour valider le travail (c'est-à-dire "si cela compile et que ça marche, c'est bon!").
Et c'est OK. Tout n'a pas besoin d'être précédé de tests rigoureux.
tl; dr
Même si construction! = Écriture de logiciels: la construction fonctionne de manière pilotée par les tests. Les conditions de "passage" pour chaque unité précèdent leur construction.
Ne confondez pas "l'exécution de tests" avec "l'écriture de tests".
Tout n'a pas besoin d'être TDD.
Vous êtes tombé dans le piège de croire à l'idée absurde que l'écriture de logiciels est analogue à la construction d'une maison. Ça ne l'est pas. C'est plus analogue à la création des dessins des architectes et des calculs des ingénieurs de structure.
Maintenant avec de vraies maisons, l'architecte crée ces plans à l'avance. Ensuite, vous appelez les constructeurs, qui commencent à construire, rencontrent des problèmes, doivent modifier les choses, prendre le contrôle du bâtiment, qui veulent des changements, etc. Qu'est-il arrivé. C'est une façon merdique de faire les choses, mais les maisons sont longues à construire et coûteuses, c'est donc le seul moyen pratique.
Les choses vont mieux pour le génie logiciel. L'équivalent de la construction de la maison est que le compilateur transforme votre code en une unité compilée (bibliothèque, application, application Web, etc.). C'est très rapide et bon marché de le faire des centaines de fois par jour. Par conséquent, cela n'a aucun sens de reconstruire la maison à plusieurs reprises lorsque vous ajoutez des fonctionnalités et d'appeler uniquement l'inspecteur (AQ) à la fin pour le tester. Au lieu de cela, si vous automatisez ces vérifications, vous pouvez demander à l'inspecteur de tout inspecter à chaque reconstruction.
Que vous suiviez un TDD strict ou une approche plus orientée test d'écrire du code, puis des tests, cela n'a pas vraiment d'importance. Je préfère la première approche, d'autres la seconde. Choisissez celui qui vous convient. L'important est de créer ces chèques au fur et à mesure. Ils vous aideront plus tard lorsque vous souhaitez modifier le code en vous avertissant des ruptures de fonctionnalités ailleurs lorsque vous modifiez quelque chose.
D'abord et avant tout le coût initial n'est pas aussi élevé que vous le pensez . Oui, vous passez plus de temps à traiter les tests que si vous ne faites aucun test. Mais si vous faites une méthode de "test après", que gaspillez-vous vraiment? Disons que TDD prend 10 heures et DDT prend 6 heures. Vos frais initiaux "supplémentaires" ne sont que de 4 heures. Maintenant, si vous appliquez une métrique de code ou une exigence comme une couverture de 90%, vos coûts TDD et DDT deviennent encore plus proches.
Vous écrirez moins de code bogué avec TDD. Même si c'est simplement parce que vous avez défini les exigences comme test, à la fin de la journée, vous pouvez prouver que votre code fait exactement ce que vous vouliez qu'il fasse. Maintenant, peut-être que vous vouliez qu'il fasse la mauvaise chose, mais ce n'est pas un bug qui est une demande de changement. C'est important. Il est plus facile de "vendre" un produit qui fonctionne, mais pourrait fonctionner différemment/mieux, alors c'est de vendre un produit qui est perçu comme ne fonctionnant pas. Avec TDD, il est littéralement impossible de passer le test et d'écrire du code qui ne fonctionne pas. Il est possible que vous n'ayez pas compris les exigences et que vous ayez écrit un code incorrect mais fonctionnel.
TDD est meilleur à mesure que la base de code vieillit. Essayez de refactoriser sans suite de tests, ou avec une suite mal implémentée. Même un simple changement peut introduire des bogues. Le fait d'avoir une suite de tests avec une bonne couverture garantit qu'à mesure que le produit évolue, il continue de fonctionner comme il se doit. Cela permet également de mettre en évidence des règles commerciales contradictoires (qui se produisent sur des périodes plus longues).
Vous ne savez pas que cela ne fonctionne pas. Sans suite de tests, vous ne savez pas si votre code fonctionne comme vous le pensez ou si cela semble fonctionner.
var foo = function(in) {
if(in == 0) {
return true
}
}
Maintenant, dans toute votre application, vous appelez if(foo()){ doStuff() } Que se passe-t-il lorsque je corrige foo?
var foo = function(in) {
if(in === 0) {
return true
}
}
Vous devriez également refactoriser et DRYing vos tests aussi. Une bonne suite de tests n'est pas difficile à maintenir. Avec des tests atomiques bien écrits, j'ai rarement eu à revenir en arrière et à changer plus de 1-2 d'entre eux à la fois. Lorsqu'il y a eu des changements plus importants dans la suite de tests, c'est un drapeau rouge géant que quelque chose ne va pas.
Je ne vois tout simplement pas comment je devrais connaître toutes mes méthodes et comment les choses fonctionneront jusqu'à ce que mon code soit là.
Tu n'es pas censé le faire. Vous êtes censé écrire un test qui teste qu'une certaine unité de travail est effectuée. Si vous avez l'impression de tester des choses que vous ne pouvez pas savoir, vous pensez trop grand, OR le test est trop petit.
Par exemple, vous devez savoir qu'une porte se ferme et se verrouille. Je testerais door.close () et door.lock () et que door.open () renvoie false lorsque la porte est verrouillée. C'est ça. Si vos tests sont door.lock () définit un indicateur dans la base de données. Ensuite, vous testez trop petit. Le test n'a pas besoin de savoir comment fonctionne door.lock (), c'est juste qu'il le fait.
Maintenant, si vous écrivez un test qui dit que house.isSecure () renvoie true lorsque toutes les portes et fenêtres sont verrouillées. Sans regarder d'abord les portes ou les fenêtres, vous pensez trop grand.
Enfin, Vous envisagez peut-être une trop grande unité de travail . Lorsque vous obtenez votre liste d'exigences, vous devez les organiser afin de travailler sur la plus petite unité. Écrivez le test pour cette unité, puis le code, puis rincez et répétez.
Essentiellement, votre compréhension (la liste) de la façon dont TDD devrait fonctionner est éteinte. Vous ne devriez jamais avoir 2/100 de passes. Vous devriez avoir 1/1 en passant, puis 2/2 en passant, puis 3/3 en passant, puis 4/4 en passant, et ainsi de suite.
Une liste révisée pour vous
- Obtenez toutes les spécifications
- Choisissez une spécification
- Essaye-le
- Codez-le
- Essaye-le
- Si les tests réussissent, passez à 7 sinon passez à 4
- Si vous avez fait toutes les spécifications, passez à 8 sinon passez à 2
- Passez en revue les spécifications avec le consommateur et ajoutez de nouvelles spécifications si nécessaire. Si cela est fait correctement, vous ne devriez pas du tout modifier les tests. Ajoutez-en simplement de nouveaux. Parfois, la collecte des exigences peut s'effondrer et vous devez ajouter des tests qui entrent en conflit avec les tests précédents, mais vous devez rarement changer les tests.
Il y a des clés dont je pense que les autres réponses manquent.
Trois avantages
Premièrement, le coût de l'erreur et le coût du changement sont si incroyablement différents entre un logiciel et une maison que certaines règles peuvent ne pas s'appliquer. Par exemple, le coût du test d'une structure physique est si élevé que vous avez besoin d'un degré élevé de confiance pour qu'elle fonctionne afin de ne pas gaspiller les tests. Avec le logiciel, si vous pouvez exécuter une suite de tests unitaires en 1 à 5 secondes, nous avons différentes options à notre disposition.
Deuxièmement, le but de l'exécution d'un test que vous prévoyez d'échouer avant d'écrire le code en cours de test est de vérifier le test lui-même. Bien sûr, cela peut sembler idiot ou inutile. Mais j'ai vu suffisamment de tests unitaires écrits d'une manière qui passera toujours, même lorsque le code en cours de test est rompu. Cela peut facilement se produire lorsque vous écrivez le code en cours de test, le testez manuellement, puis écrivez le test unitaire. Si vous écrivez un test unitaire, voyez qu'il échoue, puis lorsque vous écrivez le code nécessaire pour le faire passer, et qu'il passe, vous savez que votre test est solide. Si le code en cours de test régresse, il y a une chance raisonnable que votre test unitaire le détecte.
Un troisième avantage du TDD, pas souvent mentionné, est que la taille et la complexité du code résultant sont souvent d'un ordre de grandeur plus petit. Je me suis toujours vanté de préférer un code simple et concis. Jusqu'à ce que je commence à pratiquer le TDD. TDD m'a montré que ce que j'aurais fait auparavant serait un code excessif. Pourquoi cela arrive-t-il? Parce que vous écrivez un test, puis écrivez du code pour réussir le test. Une fois le test réussi, vous avez terminé. Si vous êtes dans cet état d'esprit, il est difficile d'écrire accidentellement du code "supplémentaire".
(Le code supplémentaire a été un problème que j'ai observé dans un produit sur lequel je travaillais. De graves problèmes provenant du code que personne n'a demandé, mais certains développeurs ont pensé que ce serait cool.)
Analyse des coûts
À certains égards, vous avez raison. Nous ne pouvions pas échapper à cette stratégie lors de la construction d'une maison. Ce serait trop cher. Mais le logiciel n'est pas une maison. Le logiciel est bon marché.
Une analogie avec une maison est le travail d'assemblage de la maison par rapport à un compilateur logiciel.
Dans un monde non TDD, les développeurs itèrent encore. Nous suivons un code -> compiler -> exécuter -> cycle de test. Nous sommes déjà dans un modèle qui s'écarte considérablement de la construction d'une maison. Si vos gens de la construction construisent un cadre de porte, puis construisent une porte, puis doivent reconstruire le cadre parce que la porte est trop grande pour cela, vous aurez un problème de coût. Ainsi, vous passez plus de temps à l'avance pour vous assurer que tout est parfait. En programmation, la plupart des projets peuvent être compilés en quelques secondes ou minutes, donc peu importe si quelque chose est imparfait dès le début. Le coût de la réflexion à l'avance sur des questions triviales l'emporte généralement sur le coût de recompilation. Ainsi, nous recompilons tout le temps.
TDD est le même principe, juste tourné pour que le test passe à l'avant. Si le test peut être rendu super bon marché (donc tout se déroule en quelques secondes), le coût de la réflexion globale, une solution parfaite et globale en une seule itération de codage big-bang l'emporte sur le coût de la refactorisation.
Sauf ...
Il y a des choses dans la programmation où ces arguments ne tiennent pas. C'est le but de l'architecture. Identifiez et planifiez dès le départ les préoccupations qui seront plus coûteuses à changer plus tard. Par exemple, vous ne choisiriez pas une base de données à la volée sans réfléchir à vos besoins, commencer à construire et simplement dire que vous pouvez la changer plus tard. Vous devez y réfléchir.
Bien que cette question ait déjà une réponse acceptée, je pense avoir quelque chose à ajouter, provenant d'un style de conception sans test écrit (tous les tests effectués manuellement par des "testeurs" suivant une procédure de test) à TDD. Ce ne sont que mes observations personnelles, même si je pense qu'elles sont assez universelles.
Lorsque vous écrivez quelque chose de nouveau, quelque chose que vous n'avez jamais fait auparavant, il n'y a pas de différence significative entre TDD et ne pas faire TDD.
Généralement, ce que vous feriez serait d'écrire un petit morceau de code pour explorer une idée, puis d'ajouter des bits codés en dur pour les "tests", puis de les compiler et/ou de les exécuter. Si cela fonctionne, vous supprimez les éléments codés en dur et généralisez le code en ajoutant des paramètres, des variables d'instance, etc.
Pensez-y. C'est exactement la même quantité de travail que TDD. La seule différence est qu'en TDD, vous écririez les bits "test" séparément dans un autre fichier et ne les supprimeriez pas à la fin. Dans TDD vous conservez votre code de test.
Bien sûr, le TDD étant légèrement plus organisé signifie qu'il reste un peu de travail à trouver pour séparer les bits de code de test de votre code réel. Mais si vous avez déjà écrit des tests unitaires, vous apprendrez à modulariser votre code pour le tester.
Je me posais beaucoup de questions à ce sujet jusqu'à ce que je fasse quelques projets de TDD. Il y a une explication très succincte et complète qui m'est apparue pendant que je faisais ceci:
Lorsque vous écrivez du code, vous devez avoir un moyen de vous assurer que le code fait quelque chose de significatif. Vous testez donc votre code. Vous pouvez faire des tests ad hoc. Cependant, les tests fonctionnent mieux si vous réfléchissez à la façon de tester avant de commencer à faire les choses. Vous concevez donc la stratégie de test avant de passer aux tests.
Maintenant que vous pensez à votre stratégie de test, vous pourriez aussi bien automatiser, au moins une partie ... Et voici que vous avez un certain niveau de TDD. Le fait que vous écriviez du code jusqu'à ce que vous passiez le test est tout à fait normal. C'est ce que vous faites de toute façon, écrivez du code jusqu'à ce que cela fonctionne. Il est maintenant facile de faire sauter les tests.
Pour des raisons dépassant la portée, vous n'écrivez pas tout en une seule fois. Vous ne concevez donc pas non plus les tests en une seule fois. Mais c'est essentiellement ce que c'est. Juste une meilleure planification des tests, vous n'écrivez pas toujours le test à l'avance. Parfois, vous en ajoutez plus à mesure que vous progressez et trouvez des bogues que vous n'aviez pas anticipés ou rendez le test plus robuste plus tard. Et parfois, vous pouvez vous retrouver à ne pas concevoir de tests, mais trouver les tests manuels laborieux pour que vous fassiez les tests plus tard.
TDD n'est donc qu'une façon extrême de voir comment vous validez votre travail.
Pourquoi est agile tout sur le développement piloté par les tests (TDD) et non le test piloté par le développement (DDT)?
Je gazouille juste ici parce que je trouve que la question suggère un fait ("l'agile est tout au sujet de TDD") que je trouve plutôt répréhensible. Toutes les réponses semblent considérer ce fait comme acquis. Ce sont de bonnes réponses si vous supposez que l'agilité concerne principalement le TDD (alias, les tests au niveau de l'unité).
https://en.wikipedia.org/wiki/Agile_software_development#Agile_methods répertorie une bonne douzaine de modèles de développement différents ou plus.
Je proposerais en particulier le développement piloté par le comportement et le développement piloté par les fonctionnalités comme matière à réflexion. Des bêtes complètement différentes qui également peuvent entraîner tous les avantages du TDD de base mais sont loin d'un simple cycle de refactorisation rouge-vert.
Donc ma réponse est:
- "DDT" (alias, écrire des tests après ou "au-dessus" de l'implémentation) ne fonctionne pas pour des raisons réelles; dès que vous obtenez une pression de temps ou d'argent, les tests sortent de la fenêtre; et juste avoir des tests au profit d'avoir des tests, c'est plutôt meh de toute façon, OMI.
- Agile n'est pas tout au sujet du développement piloté par les tests (TDD) si vous interprétez ce terme comme signifiant essentiellement "des tests unitaires pour tous les blocs de construction/classes" (qui , du moins selon Wikipédia, c'est le cas). TDD n'est qu'une possibilité de faire du développement agile.
- Il existe d'autres méthodes, comme BDD ou FDD, qui font une approche de pile complète. Vous écrivez toujours vos scénarios à l'avance, vous avez toujours un cycle de refactorisation rouge-vert, et vous n'implémentez toujours que jusqu'à ce que vos scénarios soient verts, mais vos "tests" par définition exercent l'ensemble du logiciel (en agissant comme une interaction utilisateur) et jamais une seule unité.
Je préfère avoir une application avec une couverture BDD/FDD complète et aucun test unitaire qu'une application avec une couverture test unitaire complète et aucun test de pile complète.
(TDD a bien sûr sa place, par exemple dans les API, mais ce n'est pas ce dont nous parlons ici.)
Encore une fois, je n'essaie pas de rétrograder toutes les autres réponses ici, juste pour souligner que la question est formulée de manière assez étroite et que le domaine a beaucoup plus à offrir.
Bien que vous ne le voyiez pas souvent écrit de cette façon, une grande partie du raisonnement derrière Agile est que la réécriture de code est meilleure que de bien l'écrire la première fois. Chaque fois que vous réécrivez du code, vous améliorez le code et vous vous améliorez. Le faire "bien" la première fois a tendance à être plus lent et plus fragile.
L'analogie de la maison n'est pas si mauvaise, mais vous devez penser à combien de temps nous connaissons la construction de maisons par rapport à combien de temps nous en savons sur le génie logiciel - la complexité du génie logiciel est également plus proche de la construction d'un long pont ou une tour de 20 étages qu'une maison. Nous devons également considérer qu'avec les nouveaux langages et outils en cours de construction, c'est comme si chaque constructeur voulait construire le bâtiment avec des formes, des tailles et des matériaux complètement différents. Chaos complet.
Cependant, l'inspection n'est pas une bonne analogie avec les tests de code. Dans les logiciels, nous ne sommes même pas au point d'avoir des inspecteurs décents (sauf vos pairs de différents niveaux de compétence). Nous n'avons pas non plus de réglementation à inspecter, à l'exception, peut-être, de "normes de codage" pour la plupart arbitraires (ce qui ressemble plus à un test de la couleur de votre peinture et de votre disposition de pelouse qu'à la structure).
Le test d'abord est plus comme si vous construisez un mur, puis vous lui appliquez une certaine pression pour assurer la stabilité avant de le soulever et de le placer sur votre maison. C'est comme mesurer la fenêtre pour vous assurer qu'elle s'insère dans le trou que vous avez laissé avant d'essayer de la placer.
Si vous deviez construire une série de ponts sans nos siècles de connaissances architecturales, de modèles, de réglementations et de mathématiques que nous avons actuellement pour prouver que nos ponts fonctionneront avant de les construire, vous testeriez et reconstruisez vos ponts BEAUCOUP.
Enfin, un point de non-analogie - avec un logiciel chaque fois que vous êtes autorisé à réécrire une section de votre code, vous améliorez considérablement votre code et vos compétences. Saisissez toutes les chances que vous pouvez pour réécrire le code. TDD peut être une excellente excuse.