Dois-je refactoriser mes tests unitaires lorsque j'extrais une classe du système en cours de test?

J'ai écrit ce cours qui fait quelques choses (c'est peut-être une violation du principe de responsabilité unique). Je me rends compte maintenant qu'une autre partie du projet a besoin d'un morceau de cette logique et la façon dont je vais l'exposer consiste à extraire une classe de mon système en cours de test d'origine.

Je prévois pouvoir le faire sans avoir à changer de code de test, mais quand j'aurai fini, vous pourriez dire que le test n'est plus un test unitaire . Il testera la classe d'origine et la classe que j'ai extraite. En d'autres termes, j'aurai un cas de test, mais deux systèmes en cours de test.

Suis-je censé refactoriser mon code de test après avoir terminé? IE: créer un ExtrolvedClassTest et y déplacer tous les tests pertinents de OriginalClassTest? Il semble que cela puisse être un peu risqué: je peux perdre une couverture dans le processus, ce n'est peut-être pas aussi simple que de déplacer un test et je finirais par réécrire un code de test que je sais utilisé auparavant, mais qui ne le peut plus, etc.

D'un autre côté, si je laisse le OriginalClassTest tel quel, je peux voir qu'il s'agit d'un problème de maintenance de test. Ce sera un peu déroutant de trouver où se trouvent les tests de la classe extraite. Votre première impression sera qu'elle n'existe pas. Au fil du temps, avec de nombreux remaniements du code de production, cela pourrait devenir un problème grave.

Je suis nouveau chez TDD, j'aimerais donc les conseils d'un expert. Merci!

Après avoir regardé ce discours étonnant "Ian Cooper: TDD, où tout s'est-il mal passé", je vais être en désaccord avec @pdr. Je pense que vous ne devriez garder que les tests originaux. Votre capacité à refactoriser votre système sous test sans casser, écrire ou modifier les tests est tout le but de l'écriture des tests en premier lieu.

Si je devais tester la classe extraite, je testerais l'implémentation plutôt que le comportement. En conséquence, mon code serait plus difficile à refactoriser à l'avenir: ces nouveaux tests échoueraient probablement même si le comportement fonctionnait toujours.

Pour la durée du développement, ayez les deux. Gardez les anciens tests comme une assurance que vous n'avez rien cassé, écrivez de nouveaux tests (à partir de zéro) pour vous aider à concevoir les classes comme elles devraient l'être.

À la fin, parcourez et supprimez tout ce qui a disparu dans les anciens tests. Soyez prudent dans cette analyse; ne supprimez pas quelque chose parce que vous pensez qu'il devrait être éteint. Démontrez-vous (ou à quelqu'un d'autre ou à un canard en caoutchouc) pourquoi il n'est plus nécessaire. Rompez le test et assurez-vous qu'un autre test rompt avec lui.

Tout ce qui reste dans les anciens tests doit être pris au cas par cas, mais surtout ils doivent être réécrits dans la nouvelle structure.

Parce que vous avez raison, vous ne voulez pas vous retrouver avec un cauchemar d'entretien. Mais vous ne voulez pas moins de couverture de chemin qu'auparavant.