Refactoring pour la testabilité sur un système existant

Question

J'ai rejoint une équipe qui travaille sur un produit.Ce produit existe depuis environ 5 ans et utilise ASP.NET WebForms.Son architecture d'origine s'est estompée au fil du temps et les choses sont devenues relativement désorganisées tout au long de la solution.Ce n'est en aucun cas terrible, mais cela peut certainement nécessiter un peu de travail ;vous savez tous ce que je veux dire.

J'ai effectué quelques refactorisations depuis mon arrivée dans l'équipe de projet il y a environ 6 mois.Certaines de ces refactorisations sont simples, Extract Method, Pull Method Up, etc.Certaines refactorisations sont plus structurelles.Ces derniers changements me rendent nerveux car il n'existe pas de suite complète de tests unitaires pour accompagner chaque composant.

Toute l'équipe est d'accord sur la nécessité d'apporter des changements structurels via le refactoring, mais notre chef de projet a exprimé certaines inquiétudes quant au fait que nous ne disposons pas de tests adéquats pour effectuer des refactorings avec la certitude que nous n'introduisons pas de bogues de régression dans le système.Il aimerait que nous écrivions d'abord plus de tests (sur l'architecture existante), puis effectuions les refactorisations.Mon argument est que la structure de classes du système est trop étroitement couplée pour écrire des tests adéquats, et qu'il serait peut-être préférable d'utiliser une approche davantage axée sur les tests pendant que nous effectuons nos refactorisations.Ce que je veux dire par là, ce n'est pas d'écrire des tests sur les composants existants, mais d'écrire des tests pour des exigences fonctionnelles spécifiques, puis de refactoriser le code existant pour répondre à ces exigences.Cela nous permettra d'écrire des tests qui auront probablement plus de longévité dans le système, plutôt que d'écrire un tas de tests « jetables ».

Quelqu'un a-t-il une expérience quant à la meilleure marche à suivre ?J'ai mes propres idées, mais j'aimerais entendre les commentaires de la communauté.

Answer 1

Les préoccupations de votre PM sont valables - assurez-vous de tester votre système avant de procéder à des refactorisations majeures.

Je recommanderais fortement de vous procurer un exemplaire du livre de Michael Feather Travailler efficacement avec le code existant (par "Legacy Code", Feathers désigne tout système qui n'est pas suffisamment couvert par les tests unitaires).C'est plein de bonnes idées sur la façon de briser les couplages et les dépendances dont vous parlez, de manière sûre et sans risquer d'introduire des bugs de régression.

Bonne chance avec le programme de refactoring ;D'après mon expérience, c'est un processus agréable et cathartique dont vous pouvez apprendre beaucoup.

Answer 2

Pouvez-vous refactoriser en parallèle ?Ce que je veux dire, c'est réécrire les éléments que vous souhaitez refactoriser en utilisant TDD, mais laisser la base de code existante en place.Ensuite, supprimez progressivement le code existant lorsque vos nouveaux tests répondent aux besoins de votre PM ?

Answer 3

Je voudrais également vous suggérer de visiter le Refactorisation site Web de Martin Fowler.Il a littéralement écrit le livre sur ce sujet.

En ce qui concerne l'introduction de tests unitaires dans l'équation, la meilleure méthode que j'ai trouvée consiste à trouver un composant de niveau supérieur et à identifier toutes les dépendances externes qu'il possède sur des objets concrets et à les remplacer par des interfaces.Une fois que vous aurez fait cela, il sera beaucoup plus facile d'écrire des tests unitaires sur votre base de code et vous pourrez le faire un composant à la fois.Mieux encore, vous n’aurez pas à jeter de tests unitaires.

Les tests unitaires ASP.Net peuvent être délicats, mais il existe de nombreux frameworks qui facilitent leur réalisation. ASP.Net MVC, et WCSF pour n'en nommer que quelques-uns.

Answer 4

Je viens de lancer une deuxième recommandation pour Travailler efficacement avec le code hérité, un excellent livre qui m'a vraiment ouvert les yeux sur le fait que presque n'importe quel code ancien/merdique/non testable peut être résolu !

Answer 5

Tout à fait d'accord avec la réponse de Ian Nelson.De plus, je commencerais à mettre en place des tests de « haut niveau » (tests fonctionnels ou de composants) pour préserver le comportement du point de vue de l'utilisateur.Ce point pourrait être la préoccupation la plus importante de votre PM.