¿Por qué Agile tiene que ver con el desarrollo dirigido por prueba (TDD) y la prueba no dirigida por desarrollo (DDT)?

Uno de los beneficios de un enfoque TDD solo se obtiene cuando también se realiza un diseño emergente.

Por lo tanto, en su primera analogía, no escribiría 100 pruebas, ya que no hay forma de que sepa cómo se verá su software.

Usted escribe una prueba. Tu lo ejecutas Fracasa. Usted escribe la unidad de código más pequeña para hacer que su prueba pase. A continuación, ejecute su prueba de nuevo. Se pasa.

Ahora escriba la siguiente prueba, repitiendo el proceso anterior.

Esto puede parecer un enfoque inútil al principio, cuando es obvio lo que debe hacer su código, pero lo mejor de este enfoque es que su cobertura de prueba siempre es alta y el diseño del código es más limpio de esta manera.

Como método, va de la mano con la programación de pares; un par escribe la prueba, el siguiente escribe el código para hacerlo pasar, luego escribe la siguiente prueba, y así sucesivamente.

Incluso utilizo este enfoque cuando escribo una nueva clase; La primera prueba es una llamada para iniciar el constructor de la clase. Pero todavía no he escrito la clase, así que falla. A continuación escribo la clase simple, vacía, y mis primeros pases de prueba.

Una vez que entras en la mentalidad, es muy difícil no estar en ella y codificar la manera "antigua".

Recomendaría trabajar en un buen entorno Agile para aprender esto, o leer algunos buenos libros de Agile (Clean Code y Clean Coder son muy buenos) para comprender mejor.

El software no es una casa. La intuición es buena, pero entiendo que no siempre es correcta.

  

Desglosar todas las especificaciones en inspección, creo que las necesitaré (ver en el futuro).

Esto no es exacto. En TDD, estás describiendo cómo quieres usar el código. Las especificaciones dicen: "Debe haber una casa, con una forma de entrar". La prueba luego dice: "Oye, quiero tener una puerta delantera, con un pomo". Esto es mucho menos visto en el futuro que comenzar con la implementación de la construcción de un marco de puerta, perilla, bloqueo de teclas, etc. (o eso dice el argumento).

  

Llame al inspector a diario (pasando 2/100).

Esto no es correcto. No estás escribiendo pruebas para la casa. Estás escribiendo pruebas para el marco de la puerta delantera, y luego las haces verdes. Luego prueba que la puerta sea sólida, haciéndola verde. Debes tener quizás una docena de pruebas como máximo en un momento dado. Por lo general, es más cerca de dos a cuatro.

Además, la analogía de "llamar al inspector" implica que la persona necesita algo de tiempo para salir y hacer su trabajo. La ejecución de pruebas unitarias para una iteración TDD debería literalmente tomar unos segundos.

  

Parece que los cambios se pueden hacer más rápido y sin la sobrecarga que TDD parece crear.

La sobrecarga es menor de lo que parece estar implicando. Unos pocos segundos para ejecutar las pruebas, tal vez una media docena de veces, no es importante para el tiempo total de desarrollo.

El problema del desarrollo primero es que a veces, cuando llegas a las pruebas, descubres que hay un problema grande . Como si pusieras la cama al lado del inodoro y nadie quiere vivir allí como una especie de problema. Cosas que tardan más en arreglarse que cualquier tipo de sobrecarga TDD. Cosas que TDD habría captado, ya que TDD te obliga a usar tu código desde el principio y a pensar en cómo interactuar con él.

  

Mis profesores en la universidad tenían que ver con la idea de Pruebas, luego Código y luego Prueba.

Todo lo dicho, TDD no es tan ubicuo. Muchos lugares todavía hacen cambios primero y muchos de los beneficios supuestos de TDD están exagerados. Lo importante es que hagas las pruebas y las hagas bien. El orden en el que haces el trabajo es menos importante.

Las similitudes entre construir una cosa física y escribir software son bastante mínimas.

Dicho esto, hay una distinción masiva que vale la pena señalar:

Hay una diferencia entre "crear una prueba" y "ejecutar una prueba".

En el ejemplo de la construcción de una casa, los requisitos y pruebas do preceden a la construcción física. Y partes del conjunto de pruebas se ejecutan continuamente , ¡incluso por varios agentes! Cuando el constructor toma un 2x4, él "prueba" la unidad de forma inmediata y automática en contra de su idea de "cómo se ve un sonido 2x4". Él no es autor de los requisitos después de que lo recoja; ejecuta comprobaciones preexistentes en él.

Del mismo modo, para una pared ensamblada, una caja eléctrica, la plomería, etc., las pruebas / requisitos ya existen; se ejecutan de forma implícita y automática por los ojos entrenados de todos en el trabajo continuamente . Otro conjunto de pruebas preexistentes se ejecutan cuando el inspector visita. Si las unidades no se crearon para pasar la prueba preexistente , fallan.

Y lo mismo para la estructura en su conjunto. Los planes preexisten la construcción. En cada paso del camino, los ingenieros están trabajando para lograr un conjunto de condiciones preexistentes a las que la estructura finalmente se probará para cuando se complete la construcción.

Dicho esto, no todos los proyectos físicos deben ir precedidos por un conjunto enorme de pruebas. Si vas a tu taller y empiezas a juntar madera para una caja de juguetes o algo así, dejando que tu intuición y creatividad te guíen, eso no es un trabajo de carpintería TDD riguroso. En ese caso, básicamente estás confiando en las leyes físicas del medio y en tus expectativas aproximadas para validar el trabajo (es decir, "si se compila y funciona, ¡es bueno!").

Y eso está bien. No todo debe ir precedido de pruebas rigurosas.

tl;dr

A pesar de que la construcción! = el software de escritura: la construcción funciona de forma controlada por pruebas. Las condiciones de "paso" para cada unidad do preceden a su buildout.

No confunda "ejecutar pruebas" con "escribir pruebas".

No todo tiene que ser TDD.

Has caído en la trampa de creer la idea absurda de que escribir software es análogo a construir una casa. No lo es Es más análogo a crear los planos de los arquitectos y los cálculos de los ingenieros estructurales.

Ahora, con casas reales, el arquitecto crea esos planos por adelantado. Luego llama a los constructores, que comienzan a construir, se encuentran con problemas, tienen que enmendar las cosas, obtener el control de la construcción, quieren cambios, etc. Luego, al final, el arquitecto regresa y le cobra más por actualizar sus dibujos para reflejarlos. que pasó. Esta es una manera horrible de hacer las cosas, pero las casas tardan mucho tiempo en construirse y son caras, por lo que es la única forma práctica.

Las cosas son mejores para la ingeniería de software. El equivalente al edificio de la casa es hacer que el compilador convierta su código en una unidad compilada de algún tipo (biblioteca, aplicación, aplicación web, etc.). Es muy rápido y barato hacer esto cientos de veces al día. Como resultado, no tiene sentido reconstruir la casa repetidamente a medida que agrega características, y solo llamar al inspector (QA) al final para probarlo. En cambio, si automatiza esas comprobaciones, puede hacer que el inspector vuelva a inspeccionar todo cada vez que reconstruya.

Si sigue un estricto TDD, o un enfoque más orientado a la prueba de escribir algún código, entonces algunas pruebas, realmente no importa. Prefiero el primer acercamiento, otros el segundo. Elige el que más te convenga. Lo importante es que crees esos controles a medida que avanzas. Lo ayudan más tarde cuando desee cambiar el código, advirtiéndole de interrupciones en la funcionalidad en otro lugar cuando cambie algo.

En primer lugar, el costo inicial no es tan alto como cree que es . Sí, pasa más tiempo tratando las pruebas que si no realiza ninguna prueba. Pero si haces un método de "prueba después", ¿qué estás perdiendo realmente? Digamos que TDD toma 10 horas, y DDT toma 6 horas. Sus costos iniciales "adicionales" son solo 4 horas. Ahora, si aplica una métrica de código o un requisito como una cobertura del 90%, entonces su TDD y DDT se harán aún más cercanos en costos.

Escribirá menos código con errores con TDD. Aunque solo haya explicado los requisitos como una prueba, al final del día puede demostrar que su código está haciendo exactamente lo que querías que hiciera Tal vez quisieras que hiciera algo incorrecto, pero ese no es un error que es una solicitud de cambio. Esto es importante. Es más fácil "vender" un producto que funciona, pero podría funcionar de manera diferente / mejor, entonces es vender un producto que se percibe como que no funciona. Con TDD es literalmente imposible pasar la prueba y escribir un código que no funciona. Es posible que no haya comprendido los requisitos y que haya escrito el código de error, pero que funciona correctamente.

TDD es mejor cuanto más viejo es el código base. Intente refactorizar sin un conjunto de pruebas o con uno mal implementado. Incluso un simple cambio puede introducir errores. Tener un conjunto de pruebas con una buena cobertura garantiza que a medida que el producto evoluciona, seguirá funcionando como debería. También ayuda a resaltar las reglas comerciales en conflicto (que ocurren durante períodos más largos).

No sabes que no funciona. Sin un conjunto de pruebas, no sabes si tu código funciona de la manera que crees o si simplemente parece estar funcionando.

var foo = function(in) {
    if(in == 0) {
      return true
    }
}

Ahora, en toda tu aplicación, llamas a if(foo()){ doStuff() } ¿Qué sucede cuando arreglo foo?

var foo = function(in) {
    if(in === 0) {
      return true
    }
}

Debes estar refactorizando y DRYing tus pruebas también. Un buen conjunto de pruebas No es difícil de mantener. Con pruebas atómicas bien escritas, rara vez tuve que regresar y cambiar más de 1-2 de ellas a la vez. Cuando ha habido cambios más grandes en el conjunto de pruebas, es una señal de alerta gigante que algo no está bien.

  

Simplemente no veo cómo debo conocer todos mis métodos y cómo funcionarán las cosas hasta que mi código esté allí.

Bueno, se supone que no. Se supone que debes escribir una prueba que prueba que alguna unidad de trabajo está hecha. Si sientes que estás probando cosas de las que no puedes saber, entonces estás pensando que es demasiado grande, O que las pruebas son demasiado pequeñas.

Por ejemplo, necesita saber que una puerta se cierra y se bloquea. Probaría door.close () y door.lock () y esa door.open () devuelve false cuando la puerta está bloqueada. Eso es. Si sus pruebas son door.lock () establece una marca en la base de datos. Entonces estás probando demasiado pequeño. La prueba no necesita saber cómo funciona door.lock (), solo que sí.

Ahora, si está escribiendo una prueba que dice que house.isSecure () devuelve true cuando todas las puertas y ventanas están cerradas. Sin mirar las puertas o ventanas primero, entonces estás pensando demasiado grande.

Finalmente, Es posible que esté considerando una unidad de trabajo demasiado grande . Cuando obtenga su lista de requisitos, debe organizarlos para que esté trabajando en la unidad más pequeña. Escriba la prueba solo para esa unidad, luego el código, luego enjuague y repita.

En esencia, su comprensión (la lista) de cómo debería funcionar la TDD está desactivada. Nunca debes tener 2/100 pases. Debes tener 1/1 pasando, luego 2/2 pasando, luego 3/3 pasando, luego 4/4 pasando, y así sucesivamente.

Una lista revisada para ti

1. Obtenga todas las especificaciones
2. Elija una especificación
3. Pruébalo
4. codifícalo
5. Pruébalo
6. Si las pruebas pasan, pasa a 7 más, ve a 4
7. Si has hecho todas las especificaciones, ve a 8 o ve a 2
8. Revise las especificaciones con el consumidor y agregue nuevas especificaciones donde sea necesario. Si se hace correctamente, no debería tener que cambiar ninguna prueba. Apenas agregue los nuevos. A veces, la recopilación de requisitos puede fracasar y debe agregar pruebas que entren en conflicto con las pruebas anteriores, pero rara vez debería cambiar las pruebas.

Hay algunas claves que creo que faltan otras respuestas.

Tres ventajas

Primero, el costo del error y el costo del cambio son tan increíblemente diferentes entre el software y una casa que es posible que algunas reglas no se apliquen. Por ejemplo, el costo de probar una estructura física es tan alto que necesita un alto grado de confianza en su funcionamiento para no perder las pruebas. Con el software, si puede ejecutar un conjunto de pruebas unitarias en 1 a 5 segundos, entonces tenemos diferentes opciones a nuestra disposición.

En segundo lugar, el propósito de ejecutar una prueba que espera que falle antes de escribir el código en prueba es verificar la prueba en sí. Claro que puede parecer tonto o derrochador. Pero he visto suficientes pruebas de unidad escritas de una manera que siempre pasarán, incluso cuando se rompe el código de prueba. Eso puede suceder fácilmente cuando escribe el código en prueba, lo prueba manualmente y luego escribe la prueba de la unidad. Si escribe una prueba de unidad, ve que falla, luego, cuando escribe el código necesario para hacerla pasar, y pasa, usted sabe que su prueba es sólida. Si el código bajo prueba regresa, existe una posibilidad razonable de que su prueba de unidad lo detecte.

Una tercera ventaja de TDD, que no se menciona con frecuencia, es que el tamaño y la complejidad del código resultante suelen ser un orden de magnitud más pequeño. Siempre me he enorgullecido de preferir un código simple y conciso. Hasta que empecé a practicar TDD. TDD me mostró que lo que habría hecho antes sería un código excesivo. ¿Por qué pasó esto? Porque escribes una prueba, luego escribes un código para hacer que la prueba pase. Cuando la prueba pasa, has terminado con ella. Si está en este estado mental, es difícil escribir accidentalmente el código "extra".

(El código adicional ha sido un problema que he observado en un producto en el que solía trabajar. Problemas graves provenientes del código que nadie solicitó, pero algunos desarrolladores pensaron que sería genial).

Análisis de costos

Así que de alguna manera, tienes razón. No pudimos salir adelante con esta estrategia al construir una casa. Sería demasiado caro. Pero el software no es una casa. El software es barato.

Una analogía con una casa es el trabajo de ensamblar la casa frente a un compilador de software.

En un mundo que no es TDD, los desarrolladores aún iteran. Seguimos un código - > compilar - > ejecutar - > ciclo de prueba. Ya estamos en un modelo que se desvía sustancialmente de la construcción de una casa. Si su personal de construcción construye un marco de puerta, entonces construya una puerta, luego tiene que reconstruir el marco porque la puerta es demasiado grande para eso, tendrá un problema de costo. Por lo tanto, pasa más tiempo por adelantado para asegurarse de que obtiene todo perfecto. En programación, la mayoría de los proyectos se pueden compilar en segundos o minutos, por lo que no importa si algo es imperfecto desde el principio. El costo de pensar asuntos triviales con anticipación generalmente supera el costo de la recompilación. Así, recompilamos todo el tiempo.

El TDD es el mismo principio, simplemente se gira para que la prueba pase al frente. Si las pruebas se pueden hacer súper baratas (por lo que todo se ejecuta en segundos), entonces el costo de pensar a través de la solución global, perfecta, en una única iteración de codificación de gran explosión supera el costo de refactorización.

Excepto...

Hay algunas cosas en la programación donde estos argumentos no se sostienen. Ese es el propósito de la arquitectura. Identifique y planifique las preocupaciones iniciales que serán más caras de cambiar más adelante. Por ejemplo, no escogería una base de datos sobre la marcha sin pensar en sus necesidades, comenzaría a construir y simplemente argumentaría que puede cambiarla más adelante. Necesitas pensarlo bien.

Solía preguntarme mucho sobre esto hasta que hice algunos proyectos de TDD. Hay una explicación muy breve y completa que se me ocurrió mientras hacía esto:

Cuando escribes un código, debes tener alguna forma de asegurarte de que el código haga algo significativo. Así que prueba su código. Usted puede hacer pruebas ad hoc. Sin embargo, las pruebas funcionan mejor si piensa en cómo realizar las pruebas antes de comenzar a hacer las cosas. Así que diseñas la estrategia de prueba antes de ir a la prueba.

Ahora que está pensando en su estrategia de prueba, también podría automatizar, al menos una parte de ella ... Y he aquí que tiene cierto nivel de TDD. El hecho de que escriba el código hasta que pase la prueba es normal. Eso es lo que haces de todos modos, escribe el código hasta que funcione. Ahora mismo es fácil destruir las pruebas.

Por razones fuera del alcance, no escribe todo de una vez. Así que tampoco diseñas las pruebas de una sola vez. Pero básicamente eso es lo que es. Solo una mejor planificación de las pruebas, no siempre se escribe la prueba por adelantado. A veces agrega más a medida que avanza y encuentra errores que no anticipó o hace que la prueba sea más sólida más adelante. Y a veces es posible que no esté diseñando pruebas, pero que las pruebas manuales resulten laboriosas, por lo que puede realizarlas más adelante.

Por lo tanto, TDD es solo una forma extrema de ver cómo validar su trabajo.

Si bien esta pregunta ya tiene una respuesta aceptada, creo que tengo algo que agregar, proveniente de un estilo de diseño de prueba no escrita (todas las pruebas realizadas manualmente por "evaluadores" después de un procedimiento de prueba) a TDD. Estas son solo mis observaciones personales, aunque creo que son bastante universales.

Cuando estás escribiendo algo nuevo, algo que nunca has hecho antes, no hay una diferencia significativa entre TDD y no hacer TDD.

En general, lo que harías es escribir un pequeño fragmento de código para explorar una idea, luego agregar algunos bits codificados para "probar" y luego compilarlos y / o ejecutarlos. Si funciona, eliminaría las cosas codificadas y generalizaría el código agregando parámetros, variables de instancia, etc.

Piénsalo. Esa es exactamente la misma cantidad de trabajo que TDD. La única diferencia es que en TDD escribiría los bits de "prueba" por separado en otro archivo y no los eliminaría al final. En TDD mantienes tu código de prueba .

Por supuesto, el hecho de que TDD esté un poco más organizado significa que hay un poco más de trabajo para averiguar cómo separar los bits de prueba de código de su código real. Pero si ha escrito pruebas unitarias antes, aprenderá cómo modularizar su código para las pruebas.

  

¿Por qué Agile es todo sobre el desarrollo dirigido por pruebas (TDD) y no por el desarrollo (DDT)?

Solo estoy haciendo canto aquí porque encuentro que la pregunta sugiere un hecho ("ágil tiene que ver con TDD") que me parece bastante objetable. Todas las respuestas parecen tomar este hecho como concedido. Son buenas respuestas si se asume que ágil se trata principalmente de TDD (a.k.a., pruebas en el nivel de la unidad).

enlace enumera una buena docena o más de modelos de desarrollo diferentes.

Ofrecería especialmente el desarrollo impulsado por el comportamiento y el desarrollo impulsado por las características como alimento para el pensamiento. Bestias completamente diferentes que también pueden llevar a todos los beneficios del TDD básico, pero están muy lejos de un simple ciclo de refactor rojo-verde.

Así que mi respuesta es:

• "DDT" (a.k.a., escribir pruebas después o "en la parte superior" de la implementación) no funciona por razones de la vida real; Tan pronto como tienes tiempo o dinero presionado, las pruebas se salen de la ventana; y solo tener pruebas para el beneficio de tener pruebas es algo así, IMO.
• Agile es no todo sobre el desarrollo dirigido por pruebas (TDD) si interpreta que el término significa básicamente "pruebas unitarias para todos los bloques de construcción / clases" (que, al menos según Wikipedia, es el caso). TDD es solo una posibilidad de hacer un desarrollo ágil.
• Hay otros métodos, como BDD o FDD, que hacen un enfoque de pila completa. Aún escribe sus escenarios por adelantado, todavía tiene un ciclo de refactor rojo-verde, y solo implementa hasta que sus escenarios sean verdes, pero sus "pruebas" por definición ejercen todo el software (actuando como interacción del usuario) y nunca una sola unidad.

Prefiero tener una aplicación con cobertura completa de BDD / FDD y ninguna prueba de unidad que una con cobertura completa de prueba de unidad y sin pruebas de pila completa.

(TDD tiene su lugar, por supuesto, por ejemplo en las API, pero no es de eso de lo que estamos hablando aquí).

Una vez más, no estoy tratando de abatir todas las demás respuestas aquí, solo señalo que la pregunta está formulada de manera bastante restringida y que el campo tiene mucho más que ofrecer.

Aunque no lo ves escrito de esta manera a menudo, gran parte del razonamiento detrás de ágil es que reescribir el código es mejor que escribirlo bien la primera vez. Cada vez que reescribes el código, mejoras el código y te superas a ti mismo. Hacerlo "bien" la primera vez tiende a ser más lento y más frágil.

La analogía de la casa no es tan mala, pero tienes que pensar cuánto tiempo hemos sabido sobre la construcción de casas y cuánto tiempo hemos sabido sobre la ingeniería de software. Además, la complejidad de la ingeniería de software está más cerca de construir. Un puente largo o torre de 20 pisos que una casa. También debemos tener en cuenta que con la creación de nuevos idiomas y herramientas es como si todos los constructores quisieran construir el edificio con formas, tamaños y materiales completamente diferentes. Caos completo.

Sin embargo, la inspección no es una buena analogía con las pruebas de código. En software, ni siquiera estamos al punto de que tengamos inspectores decentes (excepto sus compañeros de varios niveles de habilidad). Tampoco tenemos regulaciones contra las que inspeccionar, excepto, quizás, algunos "estándares de codificación" en su mayoría arbitrarios (que es más como probar el color de su pintura y la distribución de su césped que la estructura).

Test-first es más como construir una pared, luego le aplicas algo de presión para asegurar la estabilidad antes de levantarla y colocarla en tu casa. Es como medir la ventana para asegurarse de que encajará en el orificio que dejaste antes de intentar colocarlo.

Si tuviera que construir una serie de puentes sin nuestros siglos de conocimientos de arquitectura, patrones, regulaciones y matemáticas que actualmente tenemos para probar que nuestros puentes funcionarán antes de construirlos, probablemente estará probando y reconstruyendo sus puentes. MUCHO.

Finalmente, un punto no analógico: con el software, cada vez que se le permite reescribir una sección de su código, mejora tanto su código como su habilidad. Aprovecha cada oportunidad que puedas para reescribir el código. TDD puede ser una gran excusa.