TDD con recursos limitados

13

Trabajo en una gran empresa, pero en un equipo de solo dos personas que desarrolla aplicaciones de LOB de escritorio. He estado investigando TDD desde hace 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 la automatización de pruebas, la mejora de la capacidad de mantenimiento, etc., pero en nuestra escala, la escritura de pruebas unitarias básicas para todos nuestros componentes fácilmente podría duplicar el tiempo de desarrollo. Dado que ya estamos poco protegidos con fechas límite extremas, no estoy seguro de qué dirección tomar. Mientras que otras prácticas como el desarrollo iterativo ágil se vuelven perfectas desde entonces, estoy un poco desgarrado por las compensaciones de productividad de TDD en un equipo pequeño.

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

    
pregunta bunglestink 29.01.2011 - 16:04

7 respuestas

14

La fea verdad es que inicialmente te ralentizará . Cualquier nuevo proceso o práctica lleva algún tiempo para acelerarse. En mi experiencia, TDD no paga con la implementación inicial tanto como lo hace 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.

Aunque soy un gran defensor de TDD (lo incorporé a mi trabajo actual) , creo que necesita tener un poco de espacio para respirar (fechas límite / plazos) con el fin de explorar y entender la práctica.

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

    
respondido por el dietbuddha 29.01.2011 - 17:42
10

El tiempo de desarrollo adicional del que habla puede ser una ilusión .

Lo que hace que TDD sea diferente a 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 maneras que conozco.

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

  • lo forzará a estructurar su código de 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 porciones más pequeñas de funcionalidades que facilitan la implementación de las tareas.
  • generalmente hace que la tarea de depuración sea menos frecuente.
respondido por el user2567 29.01.2011 - 16:12
8

error común, déjame gritarlo:

LAS PRUEBAS EN TDD SON PARA CARACTERÍSTICAS

EOM.

Editar: déjeme elaborar: "escribir ... pruebas de unidad para todos o nuestros componentes" es prueba de unidad , no TDD. Rutinariamente uso TDD en equipos de un solo hombre con gran éxito; La recompensa es extraordinaria.

    
respondido por el Steven A. Lowe 30.01.2011 - 04:25
3

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

    
respondido por el Dimitrios Mistriotis 30.01.2011 - 12:11
1

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

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

  2. ¿Con qué frecuencia una edición aparentemente sencilla para refactorizar el código o agregar una nueva característica rompe algo que aparentemente no tiene relación? De nuevo, con una buena cobertura de pruebas, se pueden reducir.

Incluso si no puedes poner números exactos en estos, deberías poder demostrar que estás gastando este tiempo de todos modos, así que también podrías gastarlo "por adelantado" y (con suerte) terminar con una mucho más estable producto.

    
respondido por el ChrisF 29.01.2011 - 16:10
1

Cuando las personas me hablan acerca de comenzar a adoptar pruebas en su equipo, siempre verifico cómo se ejecutarán las pruebas. A menudo los equipos no tienen una estructura continua en su lugar. Si tiene recursos limitados, sugeriría que la configuración de un servidor de CI sea un requisito previo para comenzar cualquier incursión seria en las pruebas.

Una vez que tengas esa configuración, simplemente comienza 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 se pueda probar y será costoso reestructurarlo.

Comience buscando lugares fáciles para comenzar con TDD: nuevas clases o módulos, con pocas dependencias. Las clases de servicios públicos y las estructuras de datos suelen ser buenas para comenzar.

Comprueba cómo cambia la forma en que piensas acerca de tu código, observa cuánto mejor es el código que generas y cuánto más seguro estás de ese código.

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

Línea inferior: desarrollo más lento, pero pocos defectos, y mucho menos tiempo para corregir errores.

    
respondido por el Gavin Clarke 30.01.2011 - 11:53
0

Aquí es donde creo que Behavior Driven Development muestra beneficios inmediatos, pero no estoy seguro de que el desarrollo basado en pruebas lo haga.

En el desarrollo orientado al comportamiento, aborda sus tickets de una manera diferente: se sienta con la persona de negocios y trabaja con ellos para definir los comportamientos que debe tener esta parte de la funcionalidad. 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 quien sea que lo ayude a usted ya ellos a comprender mejor qué debe hacer el sistema para que todos estén contentos con esa funcionalidad. Qué debe hacer para poder ser aceptado por el proceso de control de calidad que tiene implementado.

Definir los criterios de prueba, luego escribir esos criterios de prueba en su conjunto de pruebas automatizado, debería reducir la cantidad de idas y vueltas que obtiene: alguien que afirma que la funcionalidad está dañada, porque se perdió algo (ya sea porque se saltó algo o porque nunca te lo contaron).

También puede ayudar a la percepción que otros tienen de su equipo: si se sienta y define lo que debe hacerse en el sistema, podría elegir "idiotas que trabajan demasiado en todo y dedican tiempo a cosas que no pedimos" , a, "gente inteligente que viene con características útiles".

TL; DR: Behavior Driven Development puede mostrar mejoras rápidamente porque está enfocado en el "cliente". Test Driven Development, para mí, parece ser sobre pruebas internas de la base de código que "a nadie" le importa y da beneficios comerciales menos obvios. (Behavior Driven Development tiene un cambio inmediato, en su cara: los ingenieros de repente están teniendo mucho más tiempo con el "cliente" o analista de negocios para tratar de hacer esto bien, lo que debería verse como algo bueno ". Oh , están teniendo una reunión sobre la Característica X, lo que significa que hay progreso en ese frente! ")

    
respondido por el RyanWilcox 25.12.2011 - 20:32

Lea otras preguntas en las etiquetas