Plus vous testez tard, plus il vous en coûtera pour écrire des tests.
Plus un bogue dure longtemps, plus il est coûteux de le réparer.
La loi des rendements décroissants garantit que vous pouvez vous mettre à l’essai en essayant de vous assurer qu’il n’ya pas de bugs.
Bouddha a enseigné la sagesse de la voie médiane. Les tests sont bons. Il y a une telle chose comme trop d'une bonne chose. La clé est de pouvoir savoir quand vous êtes en déséquilibre.
Chaque ligne de code que vous écrivez sans test entraînera des coûts beaucoup plus élevés pour l'ajout de tests plus tard que si vous aviez écrit les tests avant l'écriture du code.
Chaque ligne de code sans test sera beaucoup plus difficile à déboguer ou à réécrire.
Chaque test que vous écrivez prendra du temps.
Chaque bug prendra du temps à corriger.
Les fidèles vous diront de ne pas écrire une seule ligne de code sans avoir au préalable écrit un test ayant échoué. Le test garantit que vous obtenez le comportement que vous attendez. Il vous permet de changer le code rapidement sans vous soucier du reste du système, car le test prouve que le comportement est le même.
Vous devez peser tout cela contre le fait que les tests n’ajoutent pas de fonctionnalités. Le code de production ajoute des fonctionnalités. Et ce sont les fonctionnalités qui paient les factures.
De manière pragmatique, j'ajoute tous les tests possibles. J'ignore les commentaires en faveur de regarder les tests. Je ne fais même pas confiance au code pour faire ce que je pense qu'il fait. Je fais confiance aux tests. Mais on m'a appris à lancer de temps en temps la grêle et à avoir de la chance.
Cependant, beaucoup de codeurs qui réussissent ne font pas de TDD. Cela ne signifie pas qu'ils ne testent pas. Ils n’insistent tout simplement pas pour que chaque ligne de code soit testée automatiquement. Même oncle Bob admet qu'il ne teste pas son interface utilisateur. Il insiste également pour que vous déplaciez toute logique en dehors de l'interface utilisateur.
En tant que métaphore du football (c'est le football américain), TDD est un bon jeu au sol. Les tests manuels uniquement lorsque vous écrivez une pile de code et espérez que cela fonctionne est un jeu passager. Vous pouvez être bon à l'un ou l'autre. Votre carrière ne fera les séries que si vous pouvez faire les deux. Cela ne fera pas le superbowl jusqu'à ce que vous sachiez quand choisir chacun. Mais si vous avez besoin d'un coup de pouce dans une direction particulière: les appels des officiels vont plus souvent contre moi lorsque je passe.
Si vous voulez essayer TDD, je vous recommande vivement de vous entraîner avant d'essayer de le faire au travail. TDD fait à mi-chemin, mi-cœur, et moitié assed est une raison majeure pour laquelle certains ne le respectent pas. C'est comme verser un verre d'eau dans un autre. Si vous ne vous engagez pas et que vous le faites rapidement et complètement, vous finissez par dribbler de l'eau sur toute la table.