Trabajo en una gran empresa, pero en un equipo de solo dos personas desarrollando aplicaciones LOB de escritorio. He estado investigando TDD durante bastante tiempo, y aunque es fácil darse cuenta de sus beneficios para aplicaciones más grandes, me está costando mucho tratar de justificar el tiempo para comenzar a usar TDD en la escala de nuestras aplicaciones.

Entiendo sus ventajas en automatizar las pruebas, mejorar la capacidad de mantenimiento, etc., pero en nuestra escala, escribir incluso pruebas unitarias básicas para todos nuestros componentes podría fácilmente duplicar el tiempo de desarrollo. Como ya tenemos poco tiempo límite, no estoy seguro de qué dirección tomar. Si bien otras prácticas, como el desarrollo iterativo ágil, son perfectas desde entonces, estoy un poco desgarrado por las compensaciones de productividad de TDD en un equipo pequeño.

¿Las ventajas de TDD valen el tiempo de desarrollo adicional en equipos pequeños con horarios muy ajustados?

La fea verdad es que inicialmente te retrasará . Cualquier nuevo proceso o práctica toma algún tiempo para aumentar. En mi experiencia, TDD no paga tanto con la implementación inicial como con el mantenimiento, la corrección de errores y la extensión. Sé que para otros hay un pago inmediato, por lo que dependerá del estilo de codificación actual de cada persona.

Si bien soy un gran defensor de TDD (lo traje a mi trabajo actual) creo que necesitas tener un pequeño respiro (fechas límite / plazos) para explorar y comprender la práctica.

Cuanto más pequeño sea su equipo, más inmediatamente podrá beneficiarse de TDD. He visto este pago en el tamaño del equipo de 6 a 3.

El tiempo de desarrollo adicional del que está hablando puede ser una ilusión .

Lo que hace que TDD sea diferente de las pruebas unitarias estándar es que no solo se usa para hacer pruebas.

TDD is a new way of developing software. Es una de las mejores formas que conozco.

Por lo tanto, no está relacionado con el tamaño de su proyecto. Extraerá los beneficios de la primera línea de código .

• te obligará a estructurar tu código de una manera que sea más fácil de mantener y reutilizar. Impulsa el diseño de su software.
• hará que la refactorización sea rápida, segura y agradable.
• le ayuda a escribir fragmentos más pequeños de funcionalidades que hacen que la implementación de tareas sea mucho más fácil.
• generalmente hace que la tarea de depuración sea menos frecuente.

error común, déjenme gritarlo:

LAS PRUEBAS EN TDD SON PARA CARACTERÍSTICAS

EOM.

Editar: déjenme explicar: "escribir ... pruebas unitarias para todos o nuestros componentes" es una prueba unitaria , no TDD. Rutinariamente uso TDD en equipos individuales con gran éxito; La recompensa es extraordinaria.

Hay un gran libro sobre TDD, El arte de las pruebas unitarias ( sitio oficial ) que tiene sus ejemplos en .net con una versión de Java en proceso. Lo bueno es que hay capítulos enteros que consideran temas como "Integrar las pruebas unitarias en la organización" - Capítulo 8 y "Trabajar con código heredado" - Capítulo 9. Aunque no soy un experto en este campo (todavía :-)) , según mi experiencia, creo que este es un buen punto de partida.

Hay un par de preguntas que necesita para obtener las respuestas:

1. ¿Cuánto tiempo pasas después del lanzamiento de la corrección de errores en el código? Si puede cuantificar esto, puede encontrar que iguala o incluso excede el tiempo "extra" que le tomaría escribir la prueba que ayudaría a evitar que ocurran estos errores.

2. ¿Con qué frecuencia una edición aparentemente sencilla para refactorizar el código o agregar una nueva característica rompe algo aparentemente no relacionado? Una vez más, con una buena cobertura de prueba, estos pueden reducirse.

Incluso si no puede poner números exactos en estos, debería ser capaz de demostrar que está pasando este tiempo de todos modos, por lo que también podría pasarlo "por adelantado" y (con suerte) terminar con un producto mucho más estable.

Cuando la gente me habla acerca de comenzar a adoptar las pruebas en su equipo, siempre compruebo primero cómo se realizarán las pruebas. A menudo, los equipos no tienen una construcción continua en su lugar. Si tiene recursos limitados, sugeriría que configurar un servidor CI es un requisito previo para comenzar cualquier incursión seria en las pruebas.

Una vez que tenga esa configuración, simplemente comience a practicar TDD. Tenga en cuenta que si el sistema no se ha desarrollado teniendo en cuenta las pruebas, es posible que tenga dificultades para hacer que el código existente sea comprobable, y será costoso reestructurarlo.

Comience buscando lugares fáciles para comenzar con TDD: nuevas clases o módulos, con pocas dependencias. Las clases de utilidad y las estructuras de datos a menudo son buenas cosas para comenzar.

Obtenga una idea de cómo cambia la forma en que piensa sobre su código, tenga en cuenta qué tan mejor es el código que produce y cuánto más confía en él.

Sé que realmente no he respondido la pregunta, pero creo que mi punto es que deberías poder hacer todo esto sin un costo adicional masivo. Al trabajar en sus primeros ejemplos, comprenderá mejor las ventajas de su proyecto.

En pocas palabras: desarrollo más lento, pero pocos defectos, mucho menos tiempo arreglando errores.

Aquí es donde creo que Behavior Driven Development muestra ganancias inmediatas, pero no estoy seguro de que el desarrollo impulsado por pruebas lo haga.

En el desarrollo impulsado por el comportamiento, usted aborda sus tickets de una manera diferente: se sienta con la persona de negocios y trabaja con ellos para definir los comportamientos que esta porción de funcionalidad debería tener. Describo esto en una entrada en mi blog (el título de la publicación: Comportamientos de escritura ).

Sentarse con la persona de negocios o con cualquier persona lo ayudará a usted y a ellos a comprender mejor lo que el sistema debe hacer para que todos estén contentos con esa funcionalidad. Lo que debe hacer para poder ser aceptado por el proceso de control de calidad que tiene implementado.

La definición de los criterios de prueba, y luego escribir esos criterios de prueba en su conjunto de pruebas automatizadas, debería reducir la cantidad de ida y vuelta que obtiene: alguien que dice que la funcionalidad está rota, porque se perdió algo (ya sea porque legítimamente se perdió algo o porque nunca se lo dijeron usted al respecto).

También puede ayudar a la percepción de otros sobre su equipo: si se sienta y define lo que se debe hacer en el sistema, podría pasar de "idiotas que diseñan todo y pasan tiempo en cosas que no pedimos", a, "gente inteligente a la que se le ocurren funciones útiles".

TL; DR: El desarrollo impulsado por el comportamiento puede mostrar mejoras rápidamente porque está enfocado en el "cliente". Test Driven Development, para mí, parece tratarse de probar los componentes internos de la base de código que a "nadie" le importa y proporciona beneficios comerciales menos obvios. (Behavior Driven Development tiene el cambio inmediato, en su cara: los ingenieros de repente tienen mucho más tiempo cara a cara con el "cliente" o el analista de negocios para tratar de hacer esto bien, lo que debería verse como algo bueno ". Oh , tienen una reunión sobre la función X, lo que significa que hay progreso en ese frente ")