¿Pueden las pruebas unitarias implementarse efectivamente con un desarrollo ágil?

Pronto estaré involucrado en un proyecto que utilizará el enfoque de gestión/desarrollo de proyectos ágiles, con 5 (o más) sprints de 2 semanas. El proyecto utilizará un patrón de diseño DDD que he encontrado en el pasado que funciona muy bien con pruebas unitarias, por lo tanto, también me entusiasma usarlo para este proyecto. El único problema se da los siguientes factores no estoy seguro de si las pruebas unitarias se puede implementar con éxito con el desarrollo ágil:¿Pueden las pruebas unitarias implementarse efectivamente con un desarrollo ágil?

Potencial de cambio constante requisitos (requisitos cambian, las pruebas se rompen, las pruebas deben actualizarse también).
Factor de tiempo (las pruebas unitarias pueden hacer que el desarrollador demore un poco más y si los requisitos cambian hacia el final de un sprint, puede haber muy poco tiempo para actualizar las pruebas y el código de producción con la mejor calidad).

Tengo la sensación de que si los requisitos cambian (especialmente si es al final de un sprint) y dados los plazos ajustados, las pruebas unitarias se convertirán en una carga. ¿Alguien tiene algún buen consejo al respecto?

Fuente

2010-07-29 Scozzard

Esta pregunta no está relacionada con el tema porque no está dentro del alcance de este sitio, como se define en [¿Qué temas puedo preguntar aquí?] (// stackoverflow.com/help/on -topic) También vea: [Qué tipos de preguntas, ¿debo evitar preguntar?] (// stackoverflow.com/help/dont-ask) Puede preguntar en [otro sitio de Stack Exchange] (// stackexchange.com/sites#name), * tal vez * [pm.se] o [softwareengineering.se]. Asegúrese de leer la página sobre temas del centro de ayuda para cualquier sitio en el que desee publicar una pregunta. – Makyen

@Makyen Esta pregunta fue publicada hace más de 7 años cuando estos otros intercambios no existían/no eran conocidos o los límites no estaban claramente definidos ... así que, gracias por la información? Qué extraña actualización. – Scozzard

@Makyen ¿Estás literalmente pasando por la publicación más antigua y dando consejos basados en el conjunto actual de preguntas frecuentes? ¡Tienes un largo camino por delante, amigo mío! – Scozzard

Creo que se corta en ambos sentidos. Por un lado, sí, las pruebas unitarias son un código adicional que requiere un mantenimiento adicional y lo retrasará un poco. Por otro lado, si los requisitos comienzan a evolucionar, contar con pruebas unitarias será un salvavidas para asegurarse de que lo que usted está cambiando todavía funcione.

Fuente

2010-07-29 23:09:24 Mathias

Su segundo punto es el más importante en mis libros. Ser capaz de cambiar las cosas con la seguridad de que el resto del sistema aún funciona hace que sea mucho más fácil hacer esos cambios. –

No creo que TDD sea muy controvertido. La mayoría de las personas está de acuerdo en que las pruebas unitarias toman tiempo pero ayudan al desarrollo (y que generalmente el beneficio supera los costos), pero no todos están convencidos de que escribir las pruebas primero sea útil. Escribir pruebas primero tiene valor como proceso de diseño, pero no funciona para todos. – Mathias

Considerando más de 10 semanas de código sin cobertura de prueba me hace temblar. ¿Cuándo tendrá tiempo para probar manualmente todo ese código? Y en virtud de los requisitos en evolución, utilizará mucho más tiempo rastreando los impactos que los cambios tendrán a lo largo de su código base.

No puedo aconsejar lo suficiente como para utilizar las pruebas unitarias. Incluso cuando se hace DDD, permita que las pruebas unitarias impulsen la implementación. Junto con buenos patrones como DI/IoC y SRP, debe encontrar tanto la base de código como las pruebas para ser más resistente al cambio, y así ahorrarle mucho tiempo durante esos sprints.

Fuente

2010-07-29 23:27:30

Trabajo en proyectos que llevan años y no tienen cobertura de prueba. No es que me guste De ningún modo. –

@Peri - Lo siento por ti, y lamentablemente, muchos proyectos son así. Es de esperar que no muchos proyectos nuevos empiecen a escatimar en pruebas automatizadas. Sin embargo, no es demasiado tarde, me han entregado sistemas con una cobertura del 0% y he podido tirar de ellos hasta un 50%, probando gradualmente las piezas a medida que han pasado por nuevos cambios. –

A menos que tenga pruebas unitarias con alta cobertura, el costo del cambio crecerá exponencialmente a medida que los proyectos avanzan. Básicamente, cuanto más anticipes el MÁS necesitarás tus pruebas unitarias.

En segundo lugar, las buenas pruebas de unidades dependen de muy pocas y pequeñas piezas en su código de producción. Cuando esto es cierto, solo algunas pruebas se verán afectadas cuando cambie una característica. Básicamente, cada prueba prueba solo una cosa y una pequeña parte del código de producción. La clave para escribir pruebas unitarias que sigan este principio es desacoplar el código y realizar pruebas de forma aislada.

En tercer lugar, debe entender mejor el concepto de DONE y por qué su definición es tan importante en términos de desarrollo sostenible. Básicamente, no puede avanzar rápidamente en el tiempo de una manera sostenible si su equipo compromete el concepto de DONE en el corto plazo.

Fuente

2010-08-11 15:26:03 Mahol25

¿Pueden las pruebas unitarias implementarse efectivamente con un desarrollo ágil?

Respuesta

Cuestiones relacionadas