Relación entre BDD y TDD

¿Cuál es la relación de BDD y TDD?

Por lo que entendí, BDD agrega dos cosas principales sobre TDD: nombres de pruebas (asegurar / debería) y pruebas de aceptación. ¿Debo seguir TDD durante el desarrollo por BDD? En caso afirmativo, ¿deberían nombrarse mis pruebas de unidad TDD con el mismo estilo de garantizar / debería?

BDD agrega un ciclo alrededor del ciclo TDD.

Entonces comienza con un comportamiento y deja que eso conduzca tus pruebas, luego deja que las pruebas dirijan el desarrollo. Idealmente, BDD es impulsado por algún tipo de prueba de aceptación, pero eso no es 100% necesario. Mientras tenga definido el comportamiento esperado, estará bien.

Entonces, digamos que estás escribiendo una página de inicio de sesión.

Comience con el camino feliz:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

Esta sintaxis dada y cuándo y luego y común es común en el desarrollo impulsado por el comportamiento. Una de las ventajas es que puede ser leída (y, con capacitación, escrita) por personas que no son desarrolladores, es decir, sus partes interesadas pueden ver la lista de comportamientos que ha definido para completar con éxito una tarea y ver si coincide con sus expectativas mucho antes de lanzar un producto incompleto.

Hay un lenguaje de secuencias de comandos, conocido como Gherkin, que se parece mucho a lo anterior y le permite escribir código de prueba detrás de las cláusulas de estos comportamientos. Debe buscar un traductor basado en Gherkin para su marco de desarrollo habitual. Eso está fuera del alcance de esta respuesta.

De todos modos, volvamos al comportamiento. Su aplicación actual aún no hace esto (si es así, ¿por qué alguien solicita un cambio?), Por lo que está fallando esta prueba, ya sea que esté utilizando un corredor de prueba o simplemente haciendo pruebas manualmente.

Así que ahora es el momento de cambiar al ciclo TDD para proporcionar esa funcionalidad.

Ya sea que esté escribiendo BDD o no, sus pruebas deben asignarse a una sintaxis común. Una de las más comunes es la sintaxis de "debería" que describió.

Escriba una prueba: ShouldAcceptValidDetails. Realice el ciclo Refactor Rojo-Verde hasta que esté satisfecho con él. ¿Pasamos ahora la prueba de comportamiento? Si no, escriba otra prueba: shouldRedirectToUserDefaultPage. Red-Green-Refactor hasta que estés feliz. Lave, enjuague, repita hasta que cumpla con los criterios establecidos en el comportamiento.

Y luego pasamos al siguiente comportamiento.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Ahora no debería haber anticipado esto para pasar su comportamiento anterior. Debe fallar esta prueba en este punto. Así que regrese a su ciclo TDD.

Y así sucesivamente hasta que tenga su página.

Recomiendo The Rspec Book para aprender más sobre BDD y TDD, incluso si no eres un desarrollador de Ruby.

Mi comprensión de eso:

• BDD comenzó como un cambio de marca de TDD para que el enfoque en el comportamiento sea más claro.
• Brinda un soporte más formal (DSL y herramientas) para centrarse en el comportamiento y las especificaciones ejecutables.
• BDD ahora se puede ver como un superconjunto de TDD. Ha crecido con el tiempo para abarcar más del lado de la obtención de requisitos de las cosas, pero aún así el lado del proceso de desarrollo es una parte central de la misma.

Entonces, para abordar el TDD hecho parte correcta de BDD. BDD comenzó como un cambio en el lenguaje de TDD para aclarar la intención del proceso. El artículo introductorio de Dan North sobre BDD explica por qué es útil centrarse en el comportamiento de la palabra en lugar de la prueba: ayuda a confirmar que no solo está creando el software correctamente, sino que también está creando el software correcto. Esto siempre fue parte de un buen enfoque TDD, pero Dan lo codificó un poco en BDD.

Lo que creo que BDD hace un poco más explícito que TDD, o al menos formaliza y proporciona soporte de herramientas, es este enfoque de dos ciclos / doble bucle / zoom-in zoom-out / outside-in. Primero describe el comportamiento esperado de la función (el bucle externo), luego amplía el bucle interno para tratar con las especificaciones de bajo nivel.

De http://www.metesreau.com/ncraft-workshop/

Gherkin junto con herramientas como Cucumber y SpecFlow proporcionan una forma de escribir esas especificaciones de características de alto nivel y luego vincularlas al código que ejecuta el código de la aplicación. Yo diría que aquí es donde BDD podría 'sentirse' diferente de TDD, pero realmente todavía está haciendo lo mismo, solo que con un poco de soporte de herramienta adicional y un DSL. Algo más cercano al TDD 'tradicional' está utilizando herramientas como rspec, nspec, spock. Estos se sienten un poco más como el mismo proceso que haría en TDD 'tradicional' pero con un lenguaje más centrado en el comportamiento.

En BDD in Action, de John Ferguson Smart (muy recomendado), aboga por un enfoque de doble bucle, comenzando con algo como jBehave en las especificaciones ejecutables de nivel externo, y luego cayendo en una herramienta como Spock para las especificaciones de bajo nivel.

BDD acerca el concepto de prueba a las partes interesadas del negocio. Gherkin está diseñado para ser legible para los negocios, y la idea de 'documentación viva', es decir, informes de progreso producidos automáticamente a partir de sus especificaciones ejecutables, se trata de dar retroalimentación a las partes interesadas.

Otra parte de BDD ahora, que es donde realmente se convierte en algo que incorpora TDD como parte de un proceso más grande, son los bits y piezas de obtención de requisitos. Ideas como la inyección de características, el mapeo de impacto y las opciones reales son parte de este lado.

Para la respuesta canónica sobre esto, podría ser mejor ir a Dan North nuevamente . Si su equipo es todo desarrollador, BDD = TDD. Si su equipo involucra a una amplia gama de partes interesadas, BDD está más cerca de XP, con TDD como parte de él.

¿Cuál es la relación de BDD y TDD?

Ellos son la misma cosa.

Por lo que entendí, BDD agrega dos cosas principales sobre TDD: nombres de pruebas (asegúrese / debería)

Eso no es realmente algo que BDD "agrega". Es solo una convención diferente que pretende facilitar la enseñanza y comprensión de TDD.

Las personas que crearon BDD enseñaban TDD, y notaron que lo más difícil de entender era que TDD no tiene absolutamente nada que ver con las pruebas. Una vez que los estudiantes superaron ese obstáculo, les fue mucho más fácil. Pero es muy difícil divorciarse de pensar en las pruebas , cuando la palabra "prueba" (o terminología relacionada como "afirmar") aparece prácticamente en todas partes . Entonces, cambiaron algunas palabras.

¡Pero son solo las palabras! No hay diferencia real entre TDD y BDD.

y pruebas de aceptación.

Las pruebas de aceptación son una parte tan importante de TDD como lo son de BDD. Nuevamente: no hay diferencia entre TDD y BDD: TDD hecho bien es BDD, BDD es TDD hecho bien.