¿Es factible introducir Test Driven Development (TDD) en un proyecto maduro?[cerrado]

Question

• Digamos que nos hemos dado cuenta del valor de TDD demasiado tarde.El proyecto ya está maduro y muchos clientes empezaron a utilizarlo.
• Digamos que las pruebas automatizadas utilizadas son en su mayoría pruebas funcionales/de sistema y hay una gran cantidad de pruebas de GUI automatizadas.
• Digamos que tenemos nuevas solicitudes de funciones y nuevos informes de errores (!).Así que todavía hay mucho desarrollo en marcha.
• Tenga en cuenta que ya habría muchos objetos comerciales sin pruebas unitarias o con pocas pruebas.
• Demasiada colaboración/relaciones entre ellos, lo que nuevamente se prueba solo a través de pruebas funcionales/de sistema de nivel superior.No hay pruebas de integración per se.
• Grandes bases de datos implementadas con muchas tablas, vistas, etc.Sólo para crear una instancia de un único objeto comercial, ya se realizan una gran cantidad de viajes de ida y vuelta a la base de datos.

¿Cómo podemos introducir TDD en esta etapa?

Burlarse parece ser el camino a seguir.Pero la cantidad de burlas que tenemos que hacer aquí parece demasiada.Parece que es necesario desarrollar una infraestructura elaborada para el sistema simulado que funciona con cosas existentes (BO, bases de datos, etc.).

¿Eso significa que TDD es una metodología adecuada sólo cuando se empieza desde cero?Me interesa conocer las estrategias factibles para introducir TDD en un producto ya maduro.

Answer 1

Crear una infraestructura simulada compleja probablemente solo oculte los problemas en su código.Le recomendaría que comience con pruebas de integración, con una base de datos de prueba, en torno a las áreas del código base que planea cambiar.Una vez que tenga suficientes pruebas para asegurarse de que no romperá nada si realiza un cambio, puede comenzar a refactorizar el código para hacerlo más comprobable.

Véase también el excelente libro de Michael Feathers. Trabajar eficazmente con código heredado, es una lectura obligada para cualquiera que esté pensando en introducir TDD en una base de código heredado.

Answer 2

Creo que es completamente factible introducir TDD en una aplicación existente; de ​​hecho, lo hice yo mismo recientemente.

Es más fácil codificar nuevas funciones en forma TDD y reestructurar el código existente para adaptarlo.De esta manera, comienza con una pequeña sección de su código probado, pero los efectos comienzan a extenderse por toda la base del código.

Si tiene un error, escriba una prueba unitaria para reproducirlo, refactorizando el código según sea necesario (a menos que el esfuerzo realmente no valga la pena).

Personalmente, no creo que haya necesidad de volverse loco e intentar adaptar las pruebas al sistema existente, ya que eso puede ser muy tedioso sin una gran cantidad de beneficios.

En resumen, comience poco a poco y su proyecto se infectará cada vez más con las pruebas.

Answer 3

Sí tu puedes.Según su descripción, el proyecto está en buena forma: ¡una gran cantidad de automatización de pruebas funcionales es un camino a seguir!En algunos aspectos, es incluso más útil que las pruebas unitarias.Recuerde que TDD != prueba unitaria, se trata de iteraciones cortas y criterios de aceptación sólidos.

Recuerde que tener un proyecto existente y aceptado en realidad facilita las pruebas: la aplicación funcional es la mejor especificación de requisitos.Así que estás en una mejor posición que alguien que sólo tiene un trozo de papel para trabajar.

Simplemente comience a trabajar en sus nuevos requisitos/correcciones de errores con un TDD.Recuerde que habrá una sobrecarga asociada con el cambio de metodología (¡asegúrese de que sus clientes estén conscientes de esto!) y probablemente espere mucha desgana por parte de los miembros del equipo que están acostumbrados a las "viejas costumbres".

No toques las cosas viejas a menos que sea necesario.Si va a tener una solicitud de mejora que afectará cosas existentes, entonces considere tiempo adicional para realizar las tareas de configuración adicionales.

Personalmente, no veo mucho valor en introducir una infraestructura compleja para las maquetas; seguramente hay una manera de lograr los mismos resultados en un modo liviano, pero obviamente depende de las circunstancias.

Answer 4

Una herramienta que puede ayudarle a probar el código heredado (suponiendo que no pueda o no tenga tiempo para refactorizarlo) es Typemock Isolator:Typemock.com Permite inyectar dependencias en el código existente sin necesidad de extraer interfaces y tal porque no utiliza técnicas de reflexión estándar (proxy dinámico, etc.), pero utiliza las API de Profiler.Se ha utilizado para probar aplicaciones que dependen de sharepoint, HTTPContext y otras áreas problemáticas.Te recomiendo que le eches un vistazo.(Trabajo como un desarrollo en esa compañía, pero es la única herramienta que no lo obliga a refactorizar el código heredado existente, ahorrándole tiempo y dinero) También recomendaría "trabajar de manera efectiva con el código heredado" para obtener más técnicas.

roy

Answer 5

Sí tu puedes.No lo haga todo a la vez, introduzca solo lo que necesita para probar un módulo cada vez que lo toque.

También puede comenzar con más pruebas de aceptación de alto nivel y avanzar desde allí (eche un vistazo a fitness para esto).

Answer 6

Comenzaría con algunas pruebas de integración básicas.Esto conseguirá la aceptación del resto del personal.Luego comience a separar las partes de su código que tienen dependencias.Trabaje para utilizar la inyección de dependencia, ya que hará que su código sea mucho más comprobable.Trate los errores como una oportunidad para escribir código comprobable.