unit testing - que - ¿Es factible introducir Test Driven Development(TDD) en un proyecto maduro?
tdd pdf (6)
Crear una infraestructura burlona compleja probablemente 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 el excelente libro de Michael Feathers Al trabajar con eficacia con el código heredado , es una lectura obligada para cualquiera que esté pensando en introducir TDD en una base de código heredado.
- Digamos que nos hemos dado cuenta de un valor de TDD demasiado tarde. El proyecto ya está maduro, buena cantidad de clientes comenzaron a usarlo.
- Supongamos que las pruebas automatizadas utilizadas son principalmente pruebas funcionales / del sistema y hay una gran cantidad de pruebas automáticas de GUI.
- Supongamos 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á un montón de objetos comerciales sin pruebas o con pocas unidades.
- Demasiadas colaboraciones / relaciones entre ellos, que nuevamente se prueban únicamente a través de pruebas funcionales / de sistema de nivel superior. Sin pruebas de integración per se.
- Grandes bases de datos con muchas tablas, vistas, etc. Solo para crear una instancia de un solo objeto de negocio ya existe una buena cantidad de viajes de ida y vuelta a la base de datos.
¿Cómo podemos presentar TDD en esta etapa?
La burla 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.
Creo que es completamente posible introducir TDD en una aplicación existente, de hecho, recientemente lo hice yo mismo.
Es más fácil codificar nuevas funcionalidades de una manera 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 y su proyecto se infectará cada vez más.
Empezaría 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.
Sí tu 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 avanzar desde allí (eche un vistazo a Fitnesse para esto).
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 el código existente sin necesidad de extraer interfaces, y tal como lo hace no utiliza técnicas de reflexión estándar (proxy dinámico, etc.), sino que utiliza las API de Profiler 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 lo obliga a refactorizar el código heredado existente, ahorrándole tiempo y dinero). También recomendaría "Trabajar eficazmente con código heredado" para obtener más técnicas.
Roy
Sí tu 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 para trabajar.
Simplemente comience a trabajar en sus nuevos requisitos / correcciones 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: seguramente hay una manera de lograr los mismos resultados en un modo ligero, pero obviamente depende de sus circunstancias.