Je refactorise une énorme classe de code héritée. Refactoring (je présume) préconise ceci:
- écrire des tests pour la classe héritée
- refactoriser le diable hors de la classe
Problème: une fois que j'ai refactorisé la classe, mes tests de l'étape 1 devront être modifiés. Par exemple, ce qui était autrefois dans une méthode héritée, peut désormais être une classe distincte à la place. Ce qui était une méthode peut être maintenant plusieurs méthodes. Le paysage entier de la classe héritée peut être effacé en quelque chose de nouveau, et donc les tests que j'écris à l'étape 1 seront presque nuls et non avenus. Essentiellement, j'ajouterai l' étape 3. réécris abondamment mes tests
A quoi bon alors écrire des tests avant refactoriser? Cela ressemble plus à un exercice académique de création de plus de travail pour moi. J'écris des tests pour la méthode maintenant et j'apprends plus sur comment tester les choses et comment la méthode héritée fonctionne. On peut l'apprendre en lisant simplement le code hérité lui-même, mais écrire des tests revient presque à me frotter le nez et à documenter cette connaissance temporaire dans des tests séparés. Donc, de cette façon, je n'ai presque pas d'autre choix que d'apprendre ce que fait le code. J'ai dit temporaire ici, car je vais refactoriser le diable du code et toute ma documentation et mes tests seront nuls pour une grande partie, sauf que mes connaissances resteront et me permettront d'être plus frais sur le refactoring.
Est-ce la vraie raison d'écrire des tests avant refactor - pour m'aider à mieux comprendre le code? Il doit y avoir une autre raison!
S'il vous plaît, expliquez!
Remarque:
Il y a ce post: Est-il judicieux d'écrire des tests pour le code hérité lorsqu'il n'y a pas de temps pour une refactorisation complète? mais il dit "écrire des tests avant refactoriser", mais ne dit pas "pourquoi", ni quoi faire si "écrire des tests" semble "un travail occupé qui sera bientôt détruit"