Il n'y a eu aucun processus de développement piloté par les tests pendant le développement en raison de délais très serrés
Cette déclaration est très préoccupante. Non pas parce que cela signifie que vous avez développé sans TDD ou parce que vous ne testez pas tout. C'est inquiétant, car cela montre que vous pensez que TDD vous ralentira et vous fera manquer un délai.
Tant que vous le voyez de cette façon, vous n'êtes pas prêt pour TDD. Le TDD n'est pas quelque chose que vous pouvez progressivement maîtriser. Soit vous savez comment le faire, soit vous ne le savez pas. Si vous essayez de le faire à mi-chemin, vous allez le faire et vous-même paraître mauvais.
TDD est quelque chose que vous devez d'abord pratiquer à la maison. Apprenez à le faire, car cela vous aide à coder maintenant . Pas parce que quelqu'un vous a dit de le faire. Pas parce que cela vous aidera lorsque vous apporterez des modifications ultérieurement. Lorsque cela devient quelque chose que vous faites parce que vous êtes pressé, vous êtes prêt à le faire de manière professionnelle.
TDD est quelque chose que vous pouvez faire dans n'importe quel magasin. Vous n'avez même pas à rendre votre code de test. Vous pouvez le garder pour vous si les autres dédaignent les tests. Lorsque vous le faites correctement, les tests accélèrent votre développement même si personne d'autre ne les exécute.
D'un autre côté, si d'autres aiment et exécutent vos tests, vous devez toujours garder à l'esprit que même dans un magasin TDD, ce n'est pas votre travail de vérifier les tests. Il s'agit de créer un code de production éprouvé. Si cela peut être testé, c'est bien.
Si vous pensez que la direction doit croire en TDD ou que vos collègues codeurs doivent prendre en charge vos tests, vous ignorez la meilleure chose que TDD fait pour vous. Il vous montre rapidement la différence entre ce que vous pensez que votre code fait et ce qu'il fait réellement.
Si vous ne voyez pas comment cela, à lui seul, peut vous aider à respecter un délai plus rapidement, alors vous n'êtes pas prêt pour TDD au travail. Vous devez vous entraîner à la maison.
Cela dit, c'est bien quand l'équipe peut utiliser vos tests pour les aider à lire votre code de production et quand la direction achètera de nouveaux outils TDD.
Est-ce une bonne idée d'écrire tous les cas de test possibles après avoir transformé l'équipe en TDD?
Peu importe ce que fait l'équipe, ce n'est pas toujours une bonne idée d'écrire tous les cas de test possibles. Écrivez les cas de test les plus utiles. La couverture à 100% du code a un coût. N'ignorez pas la loi des rendements décroissants simplement parce qu'il est difficile d'émettre un jugement.
Économisez votre énergie de test pour la logique métier intéressante. Le truc qui prend des décisions et applique la politique. Testez le diable de cela. Un code de colle structurelle évident et facile à lire qui ne fait que câbler des éléments n'a pas besoin d'être testé aussi mal.
(1) Est-ce toujours correct ou une bonne idée d'arrêter la plupart du développement et de commencer à écrire des cas de test entiers possibles depuis le début, même si tout fonctionne complètement bien (encore!)? Ou
Non, c'est la pensée "faisons une réécriture complète". Cela détruit les connaissances durement acquises. Ne demandez pas à la direction le temps d'écrire des tests. Écrivez simplement des tests. Une fois que vous savez ce que vous faites, les tests ne vous ralentiront pas.
(2) il est préférable d'attendre que quelque chose de mauvais se produise et d'écrire de nouveaux tests unitaires pendant la correction
(3) oubliez même les codes précédents et écrivez simplement des tests unitaires pour les nouveaux codes uniquement et reportez tout au prochain refactor majeur.
Je répondrai 2 et 3 de la même manière. Lorsque vous changez le code, pour une raison quelconque, c'est vraiment bien si vous pouvez glisser un test. Si le code est hérité, il n'accueille actuellement pas de test. Ce qui signifie qu'il est difficile de le tester avant de le changer. Eh bien, puisque vous le changez de toute façon, vous pouvez le changer en quelque chose de testable et le tester.
C'est l'option nucléaire. C'est risqué. Vous apportez des modifications sans tests. Il existe quelques astuces créatives pour tester le code hérité avant de le modifier. Vous recherchez ce que l'on appelle des coutures qui vous permettent de modifier le comportement de votre code sans changer le code. Vous modifiez les fichiers de configuration, créez des fichiers, tout ce qu'il faut.
Michael Feathers nous a donné un livre à ce sujet: Travailler efficacement avec le code hérité . Lisez-le et vous verrez que vous n'avez pas à brûler tout ce qui est ancien pour faire quelque chose de nouveau.