je ne vois pas ce qui risque d'être cassé si ton outil de refactoring fonctionne correctement !
En fait je prends refactoring au sens large. Ca comprends donc tout ce qui est gérable par un outils de refactoring mais aussi, la suppression de code mort (est-il bien mort d'ailleurs), la réecriture de code pourave
, changement de structures de données inefficaces, réécriture de requêtes, etc.
Et souvent, sur des projets avec test unitaire, j'ai choppé des différences de comportement, minimes, mais en fait pas tant que ça: par exemple une methode renvoit une liste vide, alors qu'un null est attendu dans certains cas. Ou alors lève une exception sur un parametre qui ne devrait pas être accépté, ms qui passait, par hasard dans l'implémentation précedende.
Au passage j'ajoute que bien souvent, on choisit les outils pour toi, et tu n'a pas forcément des choses aussi puissante que eclipse,
après, il faut toujours avoir la possibilité de revenir en arrière (sauvegarde et/ou fonction proposé par l'outil)
On est d'accord. Mais il te faut un retour pour savoir si tu retournes ou non en arrière: le premier retour c'est les tests unitaires.
De plus, une fois le code livré, le "undo" c'est plus compliqué.
Dans le meilleurs des cas la validation chope le bug, et ça fait un bug interne. Tu reviens à la version qui marche.
Mais souvent: la validation n'est pas efficace, et bien souvent les tests sont réalisés à la main, et donc il est très rare que l'equipe de validation refasse des tests sur des choses déjà testés et qui marchaient avant.
[^] # Re: test unitaires?
Posté par パパフラクス . En réponse au journal Un quart des développeurs ne testent jamais leurs programmes.. Évalué à 5.
En fait je prends refactoring au sens large. Ca comprends donc tout ce qui est gérable par un outils de refactoring mais aussi, la suppression de code mort (est-il bien mort d'ailleurs), la réecriture de code pourave
, changement de structures de données inefficaces, réécriture de requêtes, etc.
Et souvent, sur des projets avec test unitaire, j'ai choppé des différences de comportement, minimes, mais en fait pas tant que ça: par exemple une methode renvoit une liste vide, alors qu'un null est attendu dans certains cas. Ou alors lève une exception sur un parametre qui ne devrait pas être accépté, ms qui passait, par hasard dans l'implémentation précedende.
Au passage j'ajoute que bien souvent, on choisit les outils pour toi, et tu n'a pas forcément des choses aussi puissante que eclipse,
après, il faut toujours avoir la possibilité de revenir en arrière (sauvegarde et/ou fonction proposé par l'outil)
On est d'accord. Mais il te faut un retour pour savoir si tu retournes ou non en arrière: le premier retour c'est les tests unitaires.
De plus, une fois le code livré, le "undo" c'est plus compliqué.
Dans le meilleurs des cas la validation chope le bug, et ça fait un bug interne. Tu reviens à la version qui marche.
Mais souvent: la validation n'est pas efficace, et bien souvent les tests sont réalisés à la main, et donc il est très rare que l'equipe de validation refasse des tests sur des choses déjà testés et qui marchaient avant.