Lorsque je dois implémenter une nouvelle fonctionnalité ou corriger un bug, j'essaie généralement de recréer la situation avec un test. Je passe parfois environ 3 heures à trouver des appareils et à écrire le test. L'implémentation des fonctionnalités ou la correction des bogues prend moins d'une heure.
Quelqu'un d'autre passe-t-il au moins 3 fois plus de temps à écrire un test que de mettre en œuvre une fonctionnalité ou de corriger un bogue? Quel est le rapport acceptable entre le temps passé à écrire le test et le code?
2
Pensez-y de cette façon: la correction du bogue prendrait-elle moins d'une heure si vous n'aviez pas de test pour confirmer qu'il existait, encore moins était-il corrigé?
—
Michael K
Réponse au titre de la question: aussi longtemps qu'il le faudra.
—
Marcelo
Je pense que l'obéissance servile aux principes du TDD, indépendamment du coût ou de la valeur commerciale, est toujours la bonne réponse.
—
Jeremy
Comment gérez-vous le cas où votre gestionnaire souhaite que vous mettiez le correctif en direct dès que possible et ne peut pas attendre un jour supplémentaire pour tester pleinement la mise en œuvre?
—
Thierry Lam
Habituellement, j'explique le coût de ne pas faire le test. Autrement dit, je peux envoyer le correctif maintenant, mais si nous n'écrivons pas le test, nous devrons refaire le tout plus tard. Parfois, ils acceptent ce coût futur, mais nous écrivons généralement les tests.
—
Christopher Bibbs