si lees todas las respuestas, todas están de acuerdo. puedes decir que eres ágil sin hacer TDD, porque 'ágil' es un manifiesto difuso, no una metodología específica. Pero no vi ninguna respuesta a continuación que diga "oh sí, la prueba primero no es necesaria" ;-)
Steven A. Lowe
Uno podría prescindir de TDD, pero ¿por qué lisiarse y caminar 7 millas en la nieve?
Trabajo
3
@ Job: esto es precisamente a lo que me refiero. Aunque "ágil" no especifica explícitamente hacer TDD, ¿se acepta generalmente, en el mundo real , que "ser ágil" incluye "hacer TDD" (o al menos pruebas unitarias)?
CraigTP
2
¿Por qué te importa tanto "ser ágil"? ¿No tiene nada más importante de qué preocuparse, como escribir software que deleite a sus clientes?
xpmatteo
1
@ShadowChaser Entiendo lo que estás diciendo, pero para ser el defensor del diablo por un momento con respecto al Punto Ágil # 1, si estuviera en un equipo que hizo un desarrollo de estilo cascada pero tuvimos una gran comunicación y colaboración entre los miembros de ese equipo, ¿eso nos haría ágiles?
CraigTP
Respuestas:
50
Sí, sí, sí, un millón de veces sí.
Agile es una filosofía, TDD es una metodología específica.
Si quisiera ser muy exigente, simplemente podría señalar que hay bastantes variaciones de xDD, que sus defensores explicarán en profundidad no son TDD, pero que todavía están sustancialmente vinculadas con la prueba primero, por lo que sería una trampa.
Entonces, digamos esto: puede ser ágil sin realizar el desarrollo de "probar primero" (mire la forma en que funciona scrum; en ningún lugar hay detalles sobre cómo escribir código). Mire un tablero kanban, mire todo tipo de metodologías ágiles.
¿Quieres pruebas unitarias? Por supuesto que sí, por todo tipo de razones, y bien podría argumentar que no puede ser ágil sin pruebas unitarias (aunque sospecho que puede serlo), pero no tiene que escribirlas primero para ser ágil.
Y, por último, es igualmente cierto que podría hacer Test First sin ser ágil y argumentos sólidos para hacer test primero, independientemente de su filosofía general de desarrollo.
Parece que otros (con un representante más SÓLIDO) tienen una opinión similar ...
+1 por esto eres ágil en la forma general en que actúas, no porque uses esa o esa metodología.
10
Las pruebas unitarias deben ser ágiles. Es solo que no tienes que escribirlos primero.
Macneil
66
@Mcneil: No tiene que escribir pruebas unitarias para "ser ágil". TDD y UT son excelentes prácticas en sí mismas, pero no se requieren ni se mencionan en el manifiesto ágil.
Martin Wickman el
44
@Marin: no hay desarrollo métodos en absoluto se mencionan en el manifiesto
Steven A. Lowe
44
Acabo de comenzar a trabajar en una gran empresa usando SCRUM para ejecutar proyectos. El proyecto en el que estoy trabajando es SCRUM (¡correctamente!) Pero el código no tiene pruebas unitarias. No tener pruebas unitarias no afecta la capacidad de usar SCRUM o ser ágil, pero sí afecta mi capacidad de confiar en la calidad del código, así como de realizar cambios rápidamente (con confianza). Dada la falta de documentación que se produce en Agile, creo que escribir pruebas primero, último o en el medio es un beneficio masivo para Agile restante (para cambiar).
Rob Gray
19
"Ser ágil" simplemente significa adherirse a los valores y principios del manifiesto ágil . Nada en ese documento menciona TDD, o incluso pruebas unitarias para el caso.
Entonces sí, puede ser ágil sin hacer TDD o pruebas unitarias.
@ Martin: bien dicho: no hay prácticas de desarrollo especificadas en el manifiesto. Es una declaración de misión, no una metodología.
Steven A. Lowe
44
@ Martin: Hay una diferencia entre un proceso ágil y los principios ágiles. Si puede nombrar un proceso ágil que no tenga pruebas, hágalo.
Macneil
@ Macneil: Scrum no tiene pruebas.
Martin Wickman el
2
@ Martin: una vez más, Scrum es un método de gestión de proyectos , no una metodología de desarrollo de software. Scrum se usa típicamente con una metodología de desarrollo ágil como XP, pero no es un sustituto de él
Steven A. Lowe
@ Steven: Gracias por aclarar mi respuesta de que Scrum no contiene prácticas de desarrollo como las pruebas. Creo que el punto ya está bien definido :-)
Martin Wickman
11
Sí ,
Mira uno de los valores ágiles:
Individuos e interacciones sobre procesos y herramientas
Eso ya debería responderlo. TDD es una determinada metodología, un proceso. De hecho, un proceso que posiblemente podría usarse en procesos de desarrollo ágiles, pero nada más. Creo que quizás TDD es lo último en tecnología ahora cuando es ágil. Pero creo que el concepto de ágil aún podrá durar, incluso si tal vez TDD ha sido reemplazado por otras prácticas.
Si vuelve a la fuente original, http://en.wikipedia.org/wiki/Extreme_Programming TDD es fundamental para el proceso; Las pruebas reemplazan las especificaciones de requisitos y los casos de uso de cascada, sirven como documentación viva y ejemplos de funcionamiento, etc. Son indispensables.
Sin embargo, hay tantos sabores diferentes de 'ágil' flotando ahora que es completamente posible que uno de ellos evite TDD
EDITAR: la interpretación de @ Murph de la pregunta parece ser la preferida. Diablos, incluso lo voté, es una buena respuesta. Sin embargo , mantengo mi posición de que el Manifiesto Ágil es un conjunto de principios, no una metodología de desarrollo. No creo que sea útil decir "oh sí, soy ágil" sin implementar realmente las prácticas que traen los beneficios. En particular:
El software de trabajo es la medida principal del progreso.
y
Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente.
Para mí, estos dos principios implican, si no requieren TDD, ¡al menos no conozco otra forma de lograrlos sin él!
EDIT 2: sí, técnicamente puedes escribir las pruebas después; pero todavía considero que test-first / TDD es fundamental. No porque no puedas "ser ágil" sin él, sino porque serás más ágil con él. Test-first / test-driven es un enfoque mucho más eficiente que test-later / test-afterthought. Las descripciones de las pruebas son los requisitos . No los pospongas hasta más tarde ;-)
EDITAR 3: Finalmente descubrí lo que me molesta tanto de la respuesta muy bien escrita de Murph. Es esa noción de que uno podría "ser ágil" sin hacerlo realmente . Y "hacerlo" (como se muestra arriba) prácticamente requiere TDD.
En ninguna parte de esa página se menciona TDD o Test First, excepto como un enlace a una página relacionada.
Murph
2
Trabajé como programador extremo en 2000-2001. Sí, escribimos pruebas unitarias, pero casi siempre escribimos el código primero, y luego probamos el código después.
Michael Shaw
1
Elección incorrecta de palabras. Reformulemos: Agile no es solo una programación extrema; Scrum y Kanban también pueden ser vistos como las metodologías ágiles y ninguno de ellos hacer cumplir el uso de DDT como la XP
t3mujin
2
@Murph: la primera oración era todo lo que importaba. @Ptolomeo: entonces lo hiciste mal ;-) @ t3mujin ¡tienes que estar bromeando!
Steven A. Lowe
44
+1: Llego tarde a la fiesta, pero esta es la única respuesta útil . Decir que podemos hacer TDD sin pruebas es como decir que podemos aprobar un examen de manejo sin saber conducir. Sí, es posible, pero difícilmente. Como dijo Michael Feathers , "Legacy Code es código sin pruebas". Y el código que, por definición, es difícil de mantener, también es difícil de trabajar cuando se utiliza un proceso ágil e iterativo.
rsenna
2
Estrictamente, eres ágil al adherirte al manifiesto ágil . En la práctica, una base de código no es ágil a menos que tenga una buena cobertura de prueba. Puede hacer TDD y escribir las pruebas antes / durante el desarrollo de la funcionalidad o escribir pruebas para la funcionalidad después de que se haya desarrollado. Sin embargo, generalmente es más fácil y efectivo hacerlo de la manera TDD.
Puede ser ágil, pero probablemente haya margen de mejora.
Uno de los principios en ágil es que debe ser capaz de responder al cambio. Esto significa que no sabe de antemano lo que tiene que construir. Si estuviera siguiendo un proceso en cascada, sabría con x meses de anticipación exactamente lo que necesita construir, y podría diseñar componentes de software individuales para que cada uno participe en un esquema más amplio, llegando al producto final (al menos pensaría que era tan). Pero como ágil dicta que no sabes cuál es el producto final, nunca sabes para qué se usará el código y, lo que es más importante, cuándo se cambiará.
Por lo tanto, necesita un conjunto de pruebas exhaustivo para asegurarse de que las características que ya ha creado continúan funcionando a medida que se modifica la base del código.
Pero eso en sí mismo no es TDD. Si escribe las pruebas después de escribir el código, no es TDD. Pero TDD ayuda con otro aspecto, evita la sobreproducción.
En mi propio equipo ágil, he estado luchando con los desarrolladores que escriben código que creen que sería útil más adelante en el proyecto. Si hubiera sido un desarrollo en cascada, probablemente estaría bien, porque estaban agregando soporte para algo en el plan del proyecto para los próximos x meses.
Pero si sigue los principios ágiles, no debe escribir este código, porque no tiene idea de si eso será necesario. La característica que fue planeada para la próxima semana puede ser pospuesta de manera indefinida.
Si sigue correctamente el principio TDD, entonces no puede existir una sola línea de código antes de que una prueba dicte esta línea de código (personalmente puedo escribir algún código trivial sin probar), y si comienza escribiendo la prueba de aceptación, entonces solo implementa exactamente lo que se necesita para ofrecer las funciones requeridas.
Por lo tanto, TDD ayuda a evitar la sobreproducción, permitiendo que el equipo sea lo más efectivo posible, que también es un principio ágil fundamental.
El software de trabajo es la medida principal del progreso.
¿Puedes ser ágil sin hacer TDD (desarrollo impulsado por pruebas)?
Respuesta corta: sí.
Respuesta más larga: ya hay muchas respuestas realmente buenas a esta pregunta y muy buenas referencias. No intentaré debatir esos puntos.
En mi experiencia, Agile se trata de elegir el nivel adecuado de Leanness para el proyecto en cuestión. ¿Qué quiero decir con Lean-ness? Y, ¿por qué lo traigo a esta respuesta?
Lean no significa cortar todo lo posible de su método. Como señaló uno de nuestros colegas, no tiene que incluir TDD o Prueba de unidad en sus comportamientos. Sin embargo, en el contexto del proyecto en el que se encuentre, puede o no ser beneficioso.
Pensemos en la cadena de suministro de un gran minorista sin nombre ubicado en AK. Ahí está el consumidor. Entran en la tienda. La tienda recibe varios productos en camión. Los camiones, presumiblemente, obtienen esos productos de un almacén. El almacén se llena con envíos de varios fabricantes. Los fabricantes a su vez tienen cadenas enteras de suministro.
¿Qué sucede cuando se le dice al gerente general de envíos en la cadena de suministro anterior que recibirá un bono anual de $ 1 millón por cada año que tenga menos de 10 camiones en la flota? Inmediatamente cortará la flota a 9 camiones. En este escenario "horrible", esto aumentará la cantidad de bienes almacenados en el almacén (aumentando el costo en ese nodo). Y "matará de hambre" los frentes de las tiendas.
Por lo tanto, la cadena de suministro general sufre si se permite la optimización local sin tener en cuenta el conjunto.
Volver a TDD y UT. TDD es un mecanismo de expresión de requisitos. El sistema DEBE cumplir con esas restricciones. Lo suficientemente justo. TDD puede reemplazar el comportamiento de requisitos de Desarrollo de casos de uso o el comportamiento de requisitos de Desarrollo guiado por la historia del usuario. Tiene el beneficio "inclinado" de combinar las cargas de trabajo de Prueba unitaria y Requisitos. Es un beneficio si la carga de trabajo general se reduce. No lo es, si aumenta la carga de trabajo de la cadena de suministro general (arreglemos la calidad).
Y entonces, preguntaste: ¿Puedes ser ágil sin hacer TDD (desarrollo impulsado por pruebas)?
Seguro que puede. Una pregunta diferente, y quizás mejor, es: - Si aplico TDD a este proyecto, ¿resultará en una entrega general de software más eficiente o menos eficiente?
Para citar a un autor favorito ... JRR Tolkien
Señor de los Anillos. Comunidad de los Anillos. Pg 94 'Y también se dice', respondió Frodo: 'No vayas a los elfos a pedir consejo, porque ambos no y sí'.
Entonces, al final, ... depende. Debes responder la pregunta. Qué camino lo llevará de manera más eficiente a su (s) objetivo (s) deseado (s).
A TDD o no a TDD. Esa sigue siendo la pregunta. :-)
Si fueras a diseñar un castillo usando Agile. Escribiría porciones que tengan funciones específicas y aliente al usuario a usar las partes funcionales, ajustando el diseño futuro a las reacciones del usuario. Entonces, si construyes la mazmorra y te comunicas con el guardián de la mazmorra, probarías los cimientos proporcionados por la tierra y la mazmorra. Construirías los parapetos y preguntarías a los vigilantes nocturnos si es bueno. Construirías las paredes y harías que los soldados probaran el valor defensivo. Construirías la cocina y harías que los cocineros la revisen. Y durante este proceso, cada parte hasta la fecha funcionaría además de la estructura actual. Entonces, cuando termines la mazmorra, podrías mover a los prisioneros. Y así sucesivamente. Pero cuando finalmente has terminado el castillo, descubres que los prisioneros escaparon.
Castillo TDD
Con TDD, apareces con los prisioneros y ves si escapan. Luego escribes las celdas de la cárcel hasta que no puedan escapar. Luego refactorizaría el código limpiamente eliminando celdas innecesarias y eliminando barras que están en la ubicación incorrecta, y volvería a probar. Los prisioneros no escaparon. No tienes que comunicarte con el carcelero. Y podrías entregar todo el castillo una vez que hayas terminado todo. En ese momento, el carcelero dice que la mazmorra necesita más celdas, y ahora tienes que desenterrar más cimientos.
Castillo ágil TDD
Si combina Agile y TDD. Verías si los prisioneros escaparon y luego preguntarías al carcelero qué se necesita. Dice que necesitas más células. Irías a buscar gente al azar para fingir ser prisioneros y ver si escapan. Si no lo hacen, entonces se lo muestras al carcelero, y él está contento con eso. Entonces comienzas a construir los parapetos.
Conclusión
Entonces ambos resuelven diferentes problemas. Agile ayuda a cambiar los requisitos en función de descubrir las necesidades de los usuarios a medida que ven que el producto se desarrolla en el punto del proceso donde es más fácil adaptarse. Implica liberar adiciones estables desglosadas del diseño general.
TDD resuelve el problema de anticipar el fracaso. Descubrir y corregir la falla tal como ocurre en un punto del proceso donde es más fácil de solucionar. Implica probar unidades de código desacopladas estables desglosadas del diseño general.
Es fácil ver TDD como una extensión de Agile, porque ambos siguen el mismo patrón, progreso y revisión impulsados por la unidad. La diferencia es que las unidades en Agile funcionan externamente en su conjunto, mientras que las unidades en TDD funcionan como una parte y pueden no producir un producto funcional para revisión externa. Y ambos procesos gobiernan diferentes necesidades (usabilidad versus corrección). Dado que ambos funcionan sobre un proceso de desarrollo en unidades, ambos procesos de revisión pueden ocurrir en puntos similares, con TDD dividido más finamente.
Notas
Tener pruebas unitarias solas no significa que use TDD. TDD significa hacerse la prueba antes de la unidad producida y usar la prueba a medida que se desarrolla para confirmar la unidad. Las pruebas unitarias sin TDD se pueden utilizar para asegurarse de que no invalide la funcionalidad creada anteriormente.
Tener sprints y otras reuniones no te hace ágil. Los objetivos del manifiesto te hacen ágil. Puede dividir los objetivos de cascada en sprints con unidades de trabajo, sin cumplir el compromiso de favorecer a las personas sobre los procesos.
Por definición de TDD y Agile. Sus pruebas unitarias regirán las unidades no entregables, por lo que TDD realizará un ciclo más rápido que Agile. Y si emplea ambos, sus ciclos Agile contendrán uno o más ciclos TDD (si se prueba cada unidad).
Por lo que entiendo: usted falla Agile al no desarrollar una unidad entregable / significativa para el usuario. La unidad puede ser significativa incluso si acelera el producto. Pero, ¿cómo explica Agile la refactorización para facilitar el mantenimiento? No lo he cubierto lo suficiente como para responder eso.
Usted falla TDD al fallar la prueba de la unidad. Producir código que no produce la función correctamente.
Agile lo obliga a abordar y mitigar los riesgos de programación y calidad en cada iteración. es decir, no se necesita TDD para ser considerado Ágil .
Sin embargo, TDD es una técnica tremenda para mitigar riesgos de calidad, especialmente para un proyecto con un gran número de iteraciones o personas. En dicho proyecto, TDD agregará cierto riesgo de programación en las primeras iteraciones, porque también debe escribir casos de prueba. Sin embargo, TDD produce grandes ahorros de costos en iteraciones posteriores porque mitiga continuamente los riesgos de calidad. es decir, se recomienda TDD.
Respuestas:
Sí, sí, sí, un millón de veces sí.
Agile es una filosofía, TDD es una metodología específica.
Si quisiera ser muy exigente, simplemente podría señalar que hay bastantes variaciones de xDD, que sus defensores explicarán en profundidad no son TDD, pero que todavía están sustancialmente vinculadas con la prueba primero, por lo que sería una trampa.
Entonces, digamos esto: puede ser ágil sin realizar el desarrollo de "probar primero" (mire la forma en que funciona scrum; en ningún lugar hay detalles sobre cómo escribir código). Mire un tablero kanban, mire todo tipo de metodologías ágiles.
¿Quieres pruebas unitarias? Por supuesto que sí, por todo tipo de razones, y bien podría argumentar que no puede ser ágil sin pruebas unitarias (aunque sospecho que puede serlo), pero no tiene que escribirlas primero para ser ágil.
Y, por último, es igualmente cierto que podría hacer Test First sin ser ágil y argumentos sólidos para hacer test primero, independientemente de su filosofía general de desarrollo.
Parece que otros (con un representante más SÓLIDO) tienen una opinión similar ...
http://www.twitter.com/unclebobmartin/status/208621409663070208
(El enlace en el tweet es la respuesta completa en LinkedIn)
fuente
"Ser ágil" simplemente significa adherirse a los valores y principios del manifiesto ágil . Nada en ese documento menciona TDD, o incluso pruebas unitarias para el caso.
Entonces sí, puede ser ágil sin hacer TDD o pruebas unitarias.
Aunque no lo recomendaría ...
fuente
Sí ,
Mira uno de los valores ágiles:
Eso ya debería responderlo. TDD es una determinada metodología, un proceso. De hecho, un proceso que posiblemente podría usarse en procesos de desarrollo ágiles, pero nada más. Creo que quizás TDD es lo último en tecnología ahora cuando es ágil. Pero creo que el concepto de ágil aún podrá durar, incluso si tal vez TDD ha sido reemplazado por otras prácticas.
Lo resumiría como:
Hoy TDD es un estándar de facto para ser ágil
Puede haber formas de ser ágil sin TDD
fuente
yo digo
No [tipo de]
Si vuelve a la fuente original, http://en.wikipedia.org/wiki/Extreme_Programming TDD es fundamental para el proceso; Las pruebas reemplazan las especificaciones de requisitos y los casos de uso de cascada, sirven como documentación viva y ejemplos de funcionamiento, etc. Son indispensables.
Sin embargo, hay tantos sabores diferentes de 'ágil' flotando ahora que es completamente posible que uno de ellos evite TDD
EDITAR: la interpretación de @ Murph de la pregunta parece ser la preferida. Diablos, incluso lo voté, es una buena respuesta. Sin embargo , mantengo mi posición de que el Manifiesto Ágil es un conjunto de principios, no una metodología de desarrollo. No creo que sea útil decir "oh sí, soy ágil" sin implementar realmente las prácticas que traen los beneficios. En particular:
y
Para mí, estos dos principios implican, si no requieren TDD, ¡al menos no conozco otra forma de lograrlos sin él!
EDIT 2: sí, técnicamente puedes escribir las pruebas después; pero todavía considero que test-first / TDD es fundamental. No porque no puedas "ser ágil" sin él, sino porque serás más ágil con él. Test-first / test-driven es un enfoque mucho más eficiente que test-later / test-afterthought. Las descripciones de las pruebas son los requisitos . No los pospongas hasta más tarde ;-)
EDITAR 3: Finalmente descubrí lo que me molesta tanto de la respuesta muy bien escrita de Murph. Es esa noción de que uno podría "ser ágil" sin hacerlo realmente . Y "hacerlo" (como se muestra arriba) prácticamente requiere TDD.
fuente
Estrictamente, eres ágil al adherirte al manifiesto ágil . En la práctica, una base de código no es ágil a menos que tenga una buena cobertura de prueba. Puede hacer TDD y escribir las pruebas antes / durante el desarrollo de la funcionalidad o escribir pruebas para la funcionalidad después de que se haya desarrollado. Sin embargo, generalmente es más fácil y efectivo hacerlo de la manera TDD.
fuente
Puede ser ágil, pero probablemente haya margen de mejora.
Uno de los principios en ágil es que debe ser capaz de responder al cambio. Esto significa que no sabe de antemano lo que tiene que construir. Si estuviera siguiendo un proceso en cascada, sabría con x meses de anticipación exactamente lo que necesita construir, y podría diseñar componentes de software individuales para que cada uno participe en un esquema más amplio, llegando al producto final (al menos pensaría que era tan). Pero como ágil dicta que no sabes cuál es el producto final, nunca sabes para qué se usará el código y, lo que es más importante, cuándo se cambiará.
Por lo tanto, necesita un conjunto de pruebas exhaustivo para asegurarse de que las características que ya ha creado continúan funcionando a medida que se modifica la base del código.
Pero eso en sí mismo no es TDD. Si escribe las pruebas después de escribir el código, no es TDD. Pero TDD ayuda con otro aspecto, evita la sobreproducción.
En mi propio equipo ágil, he estado luchando con los desarrolladores que escriben código que creen que sería útil más adelante en el proyecto. Si hubiera sido un desarrollo en cascada, probablemente estaría bien, porque estaban agregando soporte para algo en el plan del proyecto para los próximos x meses.
Pero si sigue los principios ágiles, no debe escribir este código, porque no tiene idea de si eso será necesario. La característica que fue planeada para la próxima semana puede ser pospuesta de manera indefinida.
Si sigue correctamente el principio TDD, entonces no puede existir una sola línea de código antes de que una prueba dicte esta línea de código (personalmente puedo escribir algún código trivial sin probar), y si comienza escribiendo la prueba de aceptación, entonces solo implementa exactamente lo que se necesita para ofrecer las funciones requeridas.
Por lo tanto, TDD ayuda a evitar la sobreproducción, permitiendo que el equipo sea lo más efectivo posible, que también es un principio ágil fundamental.
fuente
¿Puedes ser ágil sin hacer TDD (desarrollo impulsado por pruebas)?
Respuesta corta: sí.
Respuesta más larga: ya hay muchas respuestas realmente buenas a esta pregunta y muy buenas referencias. No intentaré debatir esos puntos.
En mi experiencia, Agile se trata de elegir el nivel adecuado de Leanness para el proyecto en cuestión. ¿Qué quiero decir con Lean-ness? Y, ¿por qué lo traigo a esta respuesta?
Lean no significa cortar todo lo posible de su método. Como señaló uno de nuestros colegas, no tiene que incluir TDD o Prueba de unidad en sus comportamientos. Sin embargo, en el contexto del proyecto en el que se encuentre, puede o no ser beneficioso.
Pensemos en la cadena de suministro de un gran minorista sin nombre ubicado en AK. Ahí está el consumidor. Entran en la tienda. La tienda recibe varios productos en camión. Los camiones, presumiblemente, obtienen esos productos de un almacén. El almacén se llena con envíos de varios fabricantes. Los fabricantes a su vez tienen cadenas enteras de suministro.
¿Qué sucede cuando se le dice al gerente general de envíos en la cadena de suministro anterior que recibirá un bono anual de $ 1 millón por cada año que tenga menos de 10 camiones en la flota? Inmediatamente cortará la flota a 9 camiones. En este escenario "horrible", esto aumentará la cantidad de bienes almacenados en el almacén (aumentando el costo en ese nodo). Y "matará de hambre" los frentes de las tiendas.
Por lo tanto, la cadena de suministro general sufre si se permite la optimización local sin tener en cuenta el conjunto.
Volver a TDD y UT. TDD es un mecanismo de expresión de requisitos. El sistema DEBE cumplir con esas restricciones. Lo suficientemente justo. TDD puede reemplazar el comportamiento de requisitos de Desarrollo de casos de uso o el comportamiento de requisitos de Desarrollo guiado por la historia del usuario. Tiene el beneficio "inclinado" de combinar las cargas de trabajo de Prueba unitaria y Requisitos. Es un beneficio si la carga de trabajo general se reduce. No lo es, si aumenta la carga de trabajo de la cadena de suministro general (arreglemos la calidad).
Y entonces, preguntaste: ¿Puedes ser ágil sin hacer TDD (desarrollo impulsado por pruebas)?
Seguro que puede. Una pregunta diferente, y quizás mejor, es: - Si aplico TDD a este proyecto, ¿resultará en una entrega general de software más eficiente o menos eficiente?
Para citar a un autor favorito ... JRR Tolkien
Entonces, al final, ... depende. Debes responder la pregunta. Qué camino lo llevará de manera más eficiente a su (s) objetivo (s) deseado (s).
A TDD o no a TDD. Esa sigue siendo la pregunta. :-)
PD: también estoy volviendo a publicar esta respuesta en otro sitio. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en
fuente
En comparación con la ingeniería de un castillo.
Castillo ágil
Si fueras a diseñar un castillo usando Agile. Escribiría porciones que tengan funciones específicas y aliente al usuario a usar las partes funcionales, ajustando el diseño futuro a las reacciones del usuario. Entonces, si construyes la mazmorra y te comunicas con el guardián de la mazmorra, probarías los cimientos proporcionados por la tierra y la mazmorra. Construirías los parapetos y preguntarías a los vigilantes nocturnos si es bueno. Construirías las paredes y harías que los soldados probaran el valor defensivo. Construirías la cocina y harías que los cocineros la revisen. Y durante este proceso, cada parte hasta la fecha funcionaría además de la estructura actual. Entonces, cuando termines la mazmorra, podrías mover a los prisioneros. Y así sucesivamente. Pero cuando finalmente has terminado el castillo, descubres que los prisioneros escaparon.
Castillo TDD
Con TDD, apareces con los prisioneros y ves si escapan. Luego escribes las celdas de la cárcel hasta que no puedan escapar. Luego refactorizaría el código limpiamente eliminando celdas innecesarias y eliminando barras que están en la ubicación incorrecta, y volvería a probar. Los prisioneros no escaparon. No tienes que comunicarte con el carcelero. Y podrías entregar todo el castillo una vez que hayas terminado todo. En ese momento, el carcelero dice que la mazmorra necesita más celdas, y ahora tienes que desenterrar más cimientos.
Castillo ágil TDD
Si combina Agile y TDD. Verías si los prisioneros escaparon y luego preguntarías al carcelero qué se necesita. Dice que necesitas más células. Irías a buscar gente al azar para fingir ser prisioneros y ver si escapan. Si no lo hacen, entonces se lo muestras al carcelero, y él está contento con eso. Entonces comienzas a construir los parapetos.
Conclusión
Entonces ambos resuelven diferentes problemas. Agile ayuda a cambiar los requisitos en función de descubrir las necesidades de los usuarios a medida que ven que el producto se desarrolla en el punto del proceso donde es más fácil adaptarse. Implica liberar adiciones estables desglosadas del diseño general.
TDD resuelve el problema de anticipar el fracaso. Descubrir y corregir la falla tal como ocurre en un punto del proceso donde es más fácil de solucionar. Implica probar unidades de código desacopladas estables desglosadas del diseño general.
Es fácil ver TDD como una extensión de Agile, porque ambos siguen el mismo patrón, progreso y revisión impulsados por la unidad. La diferencia es que las unidades en Agile funcionan externamente en su conjunto, mientras que las unidades en TDD funcionan como una parte y pueden no producir un producto funcional para revisión externa. Y ambos procesos gobiernan diferentes necesidades (usabilidad versus corrección). Dado que ambos funcionan sobre un proceso de desarrollo en unidades, ambos procesos de revisión pueden ocurrir en puntos similares, con TDD dividido más finamente.
Notas
fuente
Agile lo obliga a abordar y mitigar los riesgos de programación y calidad en cada iteración. es decir, no se necesita TDD para ser considerado Ágil .
Sin embargo, TDD es una técnica tremenda para mitigar riesgos de calidad, especialmente para un proyecto con un gran número de iteraciones o personas. En dicho proyecto, TDD agregará cierto riesgo de programación en las primeras iteraciones, porque también debe escribir casos de prueba. Sin embargo, TDD produce grandes ahorros de costos en iteraciones posteriores porque mitiga continuamente los riesgos de calidad. es decir, se recomienda TDD.
fuente