asp.net - test - code metrics visual studio 2017
Refactorización de Testability en un sistema existente (5)
Me uní a un equipo que trabaja en un producto. Este producto ha existido durante ~ 5 años aproximadamente y utiliza ASP.NET WebForms. Su arquitectura original se ha desvanecido con el tiempo, y las cosas se han vuelto relativamente desorganizadas a lo largo de la solución. De ninguna manera es terrible, pero definitivamente puede usar un poco de trabajo; todos ustedes saben lo que quiero decir
He estado realizando algunas refactorizaciones desde que llegué al equipo del proyecto hace unos 6 meses. Algunas de esas refactorizaciones son simples, Método de extracción, Método de extracción, etc. Algunas de las refactorizaciones son más estructurales. Los últimos cambios me ponen nervioso ya que no hay un conjunto completo de pruebas unitarias para acompañar cada componente.
Todo el equipo está a cargo de la necesidad de realizar cambios estructurales a través de la refactorización, pero nuestro Gerente de Proyecto ha expresado algunas preocupaciones de que no tenemos las pruebas adecuadas para hacer refactorizaciones con la confianza de que no estamos introduciendo errores de regresión en el sistema. A él le gustaría que escribiéramos más pruebas primero (en contra de la arquitectura existente), luego realizamos las refactorizaciones. Mi argumento es que la estructura de clases del sistema está demasiado unida para escribir pruebas adecuadas, y que usar un enfoque más basado en la prueba mientras realizamos nuestras refactorizaciones puede ser mejor. Lo que quiero decir con esto no es escribir pruebas contra los componentes existentes, sino escribir pruebas para requisitos funcionales específicos, luego refactorizar el código existente para cumplir esos requisitos. Esto nos permitirá escribir pruebas que probablemente tendrán más longevidad en el sistema, en lugar de escribir un montón de pruebas "descartadas".
¿Alguien tiene alguna experiencia en cuanto a cuál es el mejor curso de acción? Tengo mis propios pensamientos, pero me gustaría escuchar algunos comentarios de la comunidad.
¿Puedes volver a factor en paralelo? Lo que quiero decir es volver a escribir las piezas que desea refactorizar utilizando TDD, pero deje la base de código existente en su lugar. ¿Luego, elimine el código existente cuando sus nuevas pruebas satisfagan las necesidades de su PM?
¡Solo lanzando una segunda recomendación para Trabajar eficazmente con Legacy Code, un excelente libro que realmente me abrió los ojos al hecho de que casi cualquier código viejo / cutre / no comprobable puede ser discutido!
Las preocupaciones de su PM son válidas: asegúrese de someter su sistema a prueba antes de realizar cualquier refactorización importante.
Recomiendo encarecidamente obtener una copia del libro de Michael Feather Working Effectively With Legacy Code (por "Legacy Code" Feathers significa cualquier sistema que no esté adecuadamente cubierto por pruebas unitarias). Esto está lleno de buenas ideas sobre cómo romper esos acoplamientos y dependencias de las que habla, de una manera segura que no correrá el riesgo de introducir errores de regresión.
Buena suerte con el programa de refactorización; en mi experiencia, es un proceso agradable y catártico desde el cual se puede aprender mucho.
También me gustaría enviar una sugerencia para visitar el sitio web de refactorización de Martin Fowler. Literalmente escribió el libro sobre esto.
En cuanto a la introducción de pruebas unitarias en la ecuación, el mejor método que he encontrado es encontrar un componente de nivel superior e identificar todas las dependencias externas que tiene sobre objetos concretos y reemplazarlos con interfaces. Una vez que hayas hecho eso, será mucho más fácil escribir pruebas unitarias contra tu base de código y puedes hacerlo un componente a la vez. Aún mejor, no tendrás que descartar ninguna prueba unitaria.
Las pruebas unitarias ASP.Net pueden ser complicadas, pero hay muchos marcos que hacen que sea más fácil hacerlo. ASP.Net MVC y WCSF por nombrar algunos.
Totalmente de acuerdo con la respuesta de Ian Nelson . Además, comenzaría a realizar algunas pruebas de "alto nivel" (pruebas funcionales o de componentes) para preservar el comportamiento desde el punto de vista del usuario. Este punto podría ser la preocupación más importante para su PM.