¿Cuáles son las principales diferencias entre TDD y BDD? [cerrado]

Test Driven Development ha estado de moda en la comunidad .NET durante los últimos años. Recientemente, escuché quejas en la comunidad ALT.NET sobre BDD. ¿Qué es? ¿Qué lo hace diferente de TDD?

Entiendo que BDD tiene más que ver con las especificaciones que con las pruebas . Está vinculado al diseño controlado por dominio (¿no te gustan estos acrónimos * DD?).

Está vinculado con una determinada forma de escribir historias de usuarios, incluidas las pruebas de alto nivel. Un ejemplo de Tom ten Thij :

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

(En su artículo, Tom ejecuta directamente esta especificación de prueba en Ruby).

El papa de BDD es Dan North . Encontrará una excelente introducción en su artículo Presentación de BDD .

Encontrará una comparación de BDD y TDD en este video . También una opinión sobre BDD como "TDD hecho bien" por Jeremy D. Miller

Actualización del 25 de marzo de 2013

El video de arriba ha estado perdido por un tiempo. Aquí hay uno reciente de Llewellyn Falco, BDD vs TDD (explicado) . Encuentro su explicación clara y al grano.

Para mí, la principal diferencia entre BDD y TDD es el enfoque y la redacción. Y las palabras son importantes para comunicar su intención.

TDD dirige el enfoque a las pruebas. Y dado que en las pruebas del "viejo mundo de las cascadas" se realizan después de la implementación, esta mentalidad conduce a una comprensión y un comportamiento incorrectos.

BDD dirige el enfoque al comportamiento y la especificación, por lo que las mentes en cascada se distraen. Por lo tanto, BDD se entiende más fácilmente como práctica de diseño y no como práctica de prueba.

Parece que hay dos tipos de BDD.

El primero es el estilo original que analiza Dan North y que causó la creación de los marcos de estilo xBehave. Para mí, este estilo es principalmente aplicable para pruebas de aceptación o especificaciones contra objetos de dominio.

El segundo estilo es el que Dave Astels popularizó y que, para mí, es una nueva forma de TDD que tiene algunos beneficios serios. Se enfoca en el comportamiento en lugar de las pruebas y también en clases de prueba pequeñas, tratando de llegar al punto en el que básicamente tenga una línea por método de especificación (prueba). Este estilo se adapta a todos los niveles de prueba y se puede hacer usando cualquier marco de prueba de unidad existente, aunque los marcos más nuevos (estilo xSpec) ayudan a enfocar el comportamiento en lugar de las pruebas.

También hay un grupo BDD que puede resultarle útil:

http://groups.google.com/group/behaviordrivendevelopment/

Test-Driven Development es una metodología de desarrollo de software de prueba primero, lo que significa que requiere escribir el código de prueba antes de escribir el código real que se probará. En palabras de Kent Beck:

El estilo aquí es escribir unas pocas líneas de código, luego una prueba que debería ejecutarse, o incluso mejor, escribir una prueba que no se ejecutará, luego escribir el código que lo hará funcionar.

Después de descubrir cómo escribir un pequeño fragmento de código, ahora, en lugar de simplemente codificar, queremos obtener comentarios inmediatos y practicar "codificar un poco, probar un poco, codificar un poco, probar un poco". Entonces inmediatamente escribimos una prueba para ello.

Entonces, TDD es una metodología técnica de bajo nivel que los programadores usan para producir código limpio que funcione.

Behavior-Driven Development es una metodología que se creó en base a TDD, pero evolucionó a un proceso que no solo concierne a programadores y probadores, sino que trata con todo el equipo y todos los interesados ​​importantes, técnicos y no técnicos. BDD comenzó con algunas preguntas simples que TDD no responde bien: ¿cuántas pruebas debo escribir? ¿Qué debería probar realmente y qué no debería? ¿Cuáles de las pruebas que escribo serán de hecho importantes para el negocio o para la calidad general del producto, y cuáles son solo mi exceso de ingeniería?

Como puede ver, tales preguntas requieren colaboración entre tecnología y negocios. Las partes interesadas comerciales y los expertos en dominios a menudo pueden decirle a los ingenieros qué tipo de pruebas suenan útiles, pero solo si las pruebas son pruebas de alto nivel que tratan aspectos comerciales importantes. BDD llama a tales pruebas comerciales "ejemplos", como en "dime un ejemplo de cómo esta característica debería comportarse correctamente", y se reserva la palabra "prueba" para verificaciones técnicas de bajo nivel, tales como validación de datos o pruebas de integraciones API. La parte importante es que, si bien las pruebas solo pueden ser creadas por programadores y evaluadores, todo el equipo de entrega puede recopilar y analizar ejemplos , por diseñadores, analistas, etc.

En una oración, una de las mejores definiciones de BDD que he encontrado hasta ahora es que BDD se trata de "tener conversaciones con expertos en el dominio y usar ejemplos para obtener una comprensión compartida del comportamiento deseado y descubrir incógnitas". La parte del descubrimiento es muy importante. A medida que el equipo de entrega recopila más ejemplos, comienzan a comprender el dominio comercial cada vez más y, por lo tanto, reducen su incertidumbre sobre algunos aspectos del producto con los que tienen que lidiar. A medida que disminuye la incertidumbre, aumenta la creatividad y la autonomía del equipo de entrega. Por ejemplo, ahora pueden comenzar a sugerir sus propios ejemplos que los usuarios comerciales no creían que fueran posibles debido a su falta de experiencia en tecnología.

Ahora, tener conversaciones con los expertos en negocios y dominios suena genial, pero todos sabemos cómo eso a menudo termina en la práctica. Comencé mi viaje con la tecnología como programador. Como programadores, se nos enseña a escribir código: algoritmos, patrones de diseño, abstracciones. O, si eres diseñador, te enseñan a diseñar—Organizar información y crear hermosas interfaces. Pero cuando conseguimos nuestros trabajos de nivel de entrada, nuestros empleadores esperan que "entreguemos valor a los clientes". Y entre esos clientes puede estar, por ejemplo ... un banco. Pero no podía saber casi nada sobre banca, excepto cómo disminuir eficientemente el saldo de mi cuenta. Por lo tanto, tendría que traducir de alguna manera lo que se espera de mí en código ... Tendría que construir un puente entre la banca y mi experiencia técnica si quiero aportar algún valor. BDD me ayuda a construir ese puente sobre una base estable de comunicación fluida entre el equipo de entrega y los expertos en el dominio.

Aprende más

Si quieres leer más sobre BDD, escribí un libro sobre el tema. "Escribir excelentes especificaciones" explora el arte de analizar los requisitos y lo ayudará a aprender cómo construir un excelente proceso de BDD y a usar ejemplos como parte central de ese proceso. El libro habla sobre el lenguaje omnipresente, la recopilación de ejemplos y la creación de las llamadas especificaciones ejecutables (pruebas automatizadas) a partir de los ejemplos, técnicas que ayudan a los equipos de BDD a entregar un excelente software a tiempo y dentro del presupuesto.

Si está interesado en comprar "Escribir excelentes especificaciones" , puede ahorrar un 39% con el código de promoción 39nicieja2 :)

He experimentado un poco con el enfoque BDD y mi conclusión prematura es que BDD es muy adecuado para usar la implementación de casos, pero no en los detalles subyacentes. TDD todavía rockea en ese nivel.

BDD también se utiliza como herramienta de comunicación. El objetivo es escribir especificaciones ejecutables que puedan entender los expertos del dominio.

Me parece que BDD es un alcance más amplio. Casi implica que se utiliza TDD, que BDD es la metodología que reúne la información y los requisitos para utilizar, entre otras cosas, las prácticas de TDD para garantizar una retroalimentación rápida.

Con mis últimos conocimientos en BDD en comparación con TDD, BDD se enfoca en especificar lo que sucederá después, mientras que TDD se enfoca en establecer un conjunto de condiciones y luego mirar la salida.

El desarrollo impulsado por el comportamiento parece centrarse más en la interacción y comunicación entre los desarrolladores y también entre los desarrolladores y los evaluadores.

El artículo de Wikipedia tiene una explicación:

Desarrollo impulsado por el comportamiento.

Sin embargo, no estoy practicando BDD.

Considere que el beneficio principal de TDD es el diseño. Debería llamarse Test Driven Design. BDD es un subconjunto de TDD, llámelo Behavior Driven Design.

Ahora considere una implementación popular de TDD - Pruebas unitarias. Las Unidades en Pruebas de Unidad son típicamente un bit de lógica que es la unidad de trabajo más pequeña que puede hacer.

Cuando juntas esas Unidades de una manera funcional para describir el Comportamiento deseado a las máquinas, necesitas entender el Comportamiento que estás describiendo a la máquina. El diseño orientado al comportamiento se enfoca en verificar la comprensión de los implementadores de los casos de uso / requisitos / lo que sea y verifica la implementación de cada característica. BDD y TDD en general cumplen el importante propósito de informar el diseño y el segundo propósito de verificar la corrección de la implementación, especialmente cuando cambia. El BDD hecho correctamente implica biz y dev (y qa), mientras que las Pruebas unitarias (posiblemente vistas incorrectamente como TDD en lugar de un tipo de TDD) generalmente se realizan en el silo de desarrollo.

Añadiría que las pruebas de BDD sirven como requisitos de vida.

BDD es en gran parte TDD hecho correctamente. Sin embargo, hay un valor adicional que ofrece BDD. Aquí hay un enlace sobre eso:

BDD es más que "TDD hecho bien"

No hay diferencia entre TDD y BDD. excepto que puede leer mejor sus pruebas y puede usarlas como requisitos. Si escribe sus requisitos con las mismas palabras que escribe las pruebas de BDD, puede venir de su cliente con algunas de sus pruebas definidas listas para escribir código.

Diferencia entre desarrollo basado en pruebas (TDD) y desarrollo basado en comportamiento (BDD)

• BDD se enfoca en el aspecto conductual del sistema en lugar del
  aspecto de implementación del sistema en el que se enfoca TDD.

• BDD ofrece una comprensión más clara de lo que debe hacer el sistema
  desde la perspectiva del desarrollador y el cliente. TDD solo
  le da al desarrollador una comprensión de lo que debe hacer el sistema.

• BDD permite que tanto el desarrollador como el cliente trabajen juntos para realizar un análisis de requisitos contenido en el código fuente del sistema.

En resumen, hay una gran diferencia entre TDD y BDD. En TDD estamos enfocados principalmente en los datos de prueba. En BDD nuestro enfoque principal es el comportamiento del proyecto para que cualquier persona que no sea de programación pueda entender la línea de código en nombre del título de ese metodo

Aquí está la instantánea rápida:

• ¡TDD es solo el proceso de probar el código antes de escribirlo!

• ¡DDD es el proceso de ser informado sobre el Dominio antes de cada ciclo de tocar código!

• ¡BDD es una implementación de TDD que trae algunos aspectos de DDD!