¿Cuál es la sobrecarga real de TDD una vez que todo el equipo está acostumbrado?

Qué porcentaje de tiempo se ahorra y cuesta al hacer TDD.

Supongo que este porcentaje de cambios de costo y recompensa durante el ciclo de vida de un proyecto.

Me imagino que la fase inicial tiene un costo mucho más alto pero con pocas recompensas. Más adelante (durante la refactorización ) obtendrá el beneficio de sus pruebas.

Escuché que entre el 30 y el 50% de su tiempo está escribiendo pruebas unitarias. Sin embargo, eso no tiene en cuenta el tiempo ahorrado de escribir esas pruebas.

¿Cuál es la experiencia de todos con esto?

Wes

EDITAR ¿ Cuál es el tiempo ahorrado y el costo del tiempo? En la corrección de errores y refactorablity?

He oído que entre el 30 y el 50% de su tiempo está escribiendo pruebas unitarias. Sin embargo, eso no tiene en cuenta el tiempo ahorrado

En mi experiencia, es más del 50%.

Una vez que ha escrito la prueba, la solución tiende a ser muy fácil. Por lo tanto, no creo que sea extraño pasar del 70% al 75% de su tiempo escribiendo pruebas, pero pasa mucho menos tiempo escribiendo el 'código de producción' (código que se está probando) y prácticamente no pasa tiempo en el depurador .

Cuanto antes encuentre un error, más barato será repararlo, y TDD lo ayudará enormemente. He trabajado en proyectos en los que pasé los últimos 2 meses (de un proyecto de 8 meses) reparando errores, y esa fase se eliminaría casi por completo con TDD.

Para mí, sin embargo, el valor real está en el mantenimiento. Heredar una base de código con pruebas lo hace tener menos miedo de alterarlo. Sientes que no rompiste nada cuando las pruebas aún pasan. Dado que no tiene miedo de hacer cambios, está dispuesto a refactorizar si algo no está bien. Lo que significa que el código se puede hacer más limpio, el diseño puede ajustarse mejor y, en teoría, se pueden aplicar cambios. Compare eso con el código vudú que todos tienen miedo de tocar.

Cada vez que ejecuta sus pruebas unitarias, se ahorra la cantidad de tiempo que le tomaría probar manualmente su código.

El 30% al 50% del tiempo que usted cita como requerido para escribir sus pruebas también se ve compensado en gran medida por los beneficios de tener un mejor diseño de software (comprobable).

Digamos que lleva cuatro veces más tiempo escribir una prueba automatizada que realizarla manualmente. Eso significa que la cuarta vez que ejecuta su prueba automatizada, se paga sola. Cada vez que ejecuta la prueba automatizada después de eso, es gratis.

Esto es válido tanto si la prueba es una prueba unitaria automatizada o una prueba funcional automatizada. No todas las pruebas funcionales se pueden automatizar, pero muchas de ellas sí. Además, la prueba automatizada es más confiable que una persona; ejecutará la prueba exactamente de la misma manera , siempre.

Tener pruebas unitarias significa que puede refactorizar la implementación subyacente de un método (por rendimiento u otras razones), y las pruebas unitarias verificarán que la funcionalidad del método no ha cambiado. Esto es especialmente cierto para TDD, donde la prueba unitaria especifica la funcionalidad del método.

TDD a menudo se mide en función de la calidad del código en lugar del tiempo y el costo invertido. Sin embargo, con una mejor calidad de código, los desarrolladores y las personas que trabajan con ellos pueden trabajar mejor (menos tiempo, menos costos, más felices, etc.). http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

Escribir pruebas es excelente para ayudar a automatizar la verificación de requisitos funcionales y no funcionales. Un video que me convenció de adoptar TDD (en realidad BDD, TDD de alto nivel): http://video.google.com/videoplay?docid=8135690990081075324#

• Escribir pruebas funcionales puede ayudar a detectar errores / problemas antes durante la fase de desarrollo . Suponga que tiene una base de código grande. Con las pruebas / especificaciones de la unidad , solo necesita ver "Todas las pruebas pasaron" / "2 pruebas fallaron, vea la línea xyz". Solo necesita un equipo de desarrolladores para desarrollar y probar. Sin pruebas unitarias / especificaciones , debe comparar manualmente las declaraciones impresas con las declaraciones esperadas, y rastrear manualmente qué métodos / clases tienen errores. Probablemente necesite dos equipos separados (desarrolladores y probadores) para hacer esto.

• Las pruebas escritas ayudan a los desarrolladores a explicar el progreso y los problemas que enfrentan.

• TDD ayuda a cumplir con el mantenimiento, la adaptabilidad y la flexibilidad del código. Alienta a los desarrolladores a escribir pequeños trozos comprobables, y ponerlos juntos en trozos comprobables más grandes. Al revés (parte de la práctica de refactorización) también funciona, con la condición de que hayamos escrito pruebas sólidas. Como resultado, podemos tener un código modular bien escrito.

Con TDD, nos complace saber cuándo:

• un cliente solicita cambios en los requisitos (requisitos satisfactorios)
• se descubren mejores formas de escribir código
• los compañeros de equipo tienen sugerencias para mejorar el código
• tenemos que explicar / pasar nuestro código a otras personas

TDD puede ser aburrido porque el proceso de desarrollo toma pequeños pasos y, por lo tanto, se vuelve muy predecible.

En nuestro caso, estimaría que está cerca del 40%. Sin embargo, no creo que hayamos pasado por una fase en la que fue más que esto. Tenemos un generador de código que escupe tanto un esqueleto de código que los desarrolladores desarrollan como un conjunto de pruebas que también se desarrolla. La mayor parte de nuestro esfuerzo de prueba se destina a rastrear (o crear) datos de prueba apropiados para garantizar que obtengamos una cobertura completa.

Las medidas importantes a largo plazo no son solo la calidad del código y la confianza del código, sino incluso más aún, no quemar al equipo haciendo pruebas sin sentido

las medidas a corto plazo serían el ROI de automatizar las pruebas

por ejemplo: la semana pasada realicé más de 1000 cambios de código debido a un cambio en la arquitectura interna, comencé el conjunto de pruebas automatizadas y me fui a dormir.

las pruebas tardaron 28 minutos en ejecutarse; Todos pasaron. La realización manual de las mismas 40+ pruebas de aceptación llevaría unas 6 horas.

Otro ejemplo: en una iteración anterior había engañado uno de los escenarios de prueba con un error sutil que las pruebas manuales probablemente no hubieran encontrado (las pruebas automatizadas realizan verificaciones de integridad de db que los probadores manuales casi nunca hacen). Tuve que ejecutar ese escenario de prueba unas 50 veces antes de que pudiera resolverlo y solucionarlo. La realización manual de las operaciones del escenario de prueba llevaría unos 50 minutos. Eso es 41.6 horas-hombre de trabajo ahorradas en un día

no hay forma de calcular por adelantado el ROI de las pruebas automáticas, porque no puede saber exactamente cuántas veces necesitará ejecutar las pruebas.

pero para mí, el ROI de las pruebas automatizadas es casi infinito

Puede ayudar mucho restringir las pruebas unitarias a algoritmos complejos, casos en los que pueden generarse automáticamente y regresiones.

La prueba de componentes a menudo hace un gran trabajo para un código bastante trivial, además de cambiar la implementación es mucho más barato porque las pruebas solo se acoplan a la interfaz.

La cobertura completa con pruebas unitarias de grano fino tiene una gran sobrecarga para cambiar o refactorizar una implementación, que es exactamente lo que afirman que facilita.