¿Es factible introducir el desarrollo impulsado por prueba (TDD) en un proyecto maduro?

Question

• Supongamos que nos hemos dado cuenta de un valor de TDD demasiado tarde. El proyecto ya está maduro, buena cantidad de clientes comenzaron a usarlo.
• Digamos que las pruebas automatizadas utilizadas son en su mayoría pruebas funcionales/del sistema y hay una gran cantidad de pruebas automatizadas de GUI.
• Digamos que tenemos nuevas solicitudes de funciones y nuevos informes de errores (!). Por lo tanto, buena parte del desarrollo continúa.
• Tenga en cuenta que ya habría un montón de objetos comerciales sin pruebas o con pocas unidades.
• Demasiadas colaboraciones/relaciones entre ellos, que de nuevo solo se prueban mediante pruebas funcionales/de sistema de nivel superior. Sin pruebas de integración per se.
• Bases de datos grandes con muchas tablas, vistas, etc. Solo para ejemplificar un único objeto de negocio ya existe una buena 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 demasiado. Parece que se necesita desarrollar una infraestructura compleja para que el sistema de imitación funcione para las cosas existentes (BO, bases de datos, etc.).

¿Eso significa que TDD es una metodología adecuada solo cuando se comienza desde cero? Estoy interesado en conocer las estrategias factibles para introducir TDD en un producto ya maduro.

Answer 1

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

Se también Michael Feathers excelente libro Working effectively with legacy code, es una lectura obligada para cualquiera que esté pensando en introducir TDD en una base de código heredado.

Answer 2

Sí, puedes. No lo haga todo de una vez, pero introduzca 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 trabajar desde allí (para más detalles, consulte Fitnesse).

Answer 3

Creo que es completamente posible introducir TDD en una aplicación existente, de hecho, recientemente lo he hecho yo mismo.

Es más fácil codificar nuevas funcionalidades en una forma TDD y reestructurar el código existente para acomodar esto. De esta forma, puede comenzar con una pequeña sección de su código probado, pero los efectos comienzan a extenderse por toda la base de códigos.

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 ninguna necesidad de volverse loco y probar y actualizar las pruebas en el sistema existente, ya que 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.

Answer 4

Sí, puedes.A partir de su descripción, el proyecto está en buena forma: la sólida cantidad de pruebas funcionales de automatización es un camino por recorrer. 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 realmente facilita las pruebas; la aplicación en funcionamiento es la mejor especificación de requisitos. Así que estás en una mejor posición que alguien que solo tiene un trozo de papel con el que trabajar.

Simplemente comience a trabajar en sus nuevos requisitos/solución de errores con un TDD. Recuerde que habrá una sobrecarga asociada con cambiar la metodología (¡asegúrese de que sus clientes estén al tanto de esto!) Y probablemente espere mucha reticencia por parte de los miembros del equipo que están acostumbrados a las "buenas costumbres".

No toque las cosas viejas a menos que lo necesite. Si va a tener una solicitud de mejora que afectará a las cosas existentes, entonces tenga en cuenta el tiempo adicional para hacer las cosas adicionales de configuración.

Personalmente no veo mucho valor en la introducción de una infraestructura compleja para maquetas - ciertamente hay una manera de lograr los mismos resultados en un modo ligero, pero es obvio que depende de sus circunstancias

Answer 5

Me gustaría empezar con algunas pruebas de integración básicas. Esto recibirá la aprobación del resto del personal. Luego comience a separar las partes de su código que tienen dependencias. Trabaja para usar Inyección de Dependencia, ya que hará que tu código sea mucho más comprobable. Trate los errores como una oportunidad para escribir un código comprobable.

Answer 6

Una herramienta que puede ayudarlo a probar el código heredado (suponiendo que no puede \ no tendrá tiempo para refactorizarlo, es Typemock Isolator: Typemock.com Permite inyectar dependencias en código existente sin necesidad de extraer interfaces y tal porque no usa técnicas de reflexión estándar (proxy dinámico, etc.) sino que usa las API de perfil en su lugar. Se ha utilizado para probar aplicaciones que se basan en sharepoint, HTTPContext y otras áreas problemáticas. Te recomiendo que eches un vistazo. (Trabajo como desarrollador en esa compañía, pero es la única herramienta que no te obliga a refactorizar el código heredado existente, ahorrándote tiempo y dinero) También recomendaría "Trabajar eficazmente con código heredado" para obtener más técnicas

Roy