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

Question

El desarrollo basado en pruebas 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 diferencia de TDD?

Answer 1

Entiendo que BDD se trata más de especificación que pruebas.Está vinculado al Domain Driven Design (¿no te encantan estas siglas *DD?).

Está vinculado con una determinada forma de escribir historias de usuarios, incluidas 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 continúa ejecutando directamente esta especificación de prueba en Ruby).

El Papa de BDD es Dan Norte.Encontrarás una gran introducción en su Presentando BDD artículo.

Encontrará una comparación de BDD y TDD en este video.También una opinión sobre BDD como "TDD bien hecho" por jeremy d.Molinero

Actualización del 25 de marzo de 2013

El vídeo de arriba ha estado perdido por un tiempo.Aquí hay uno reciente de Llewellyn Falco, BDD frente a TDD (explicado).Su explicación me parece clara y al grano.

Answer 2

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 se centra en las pruebas.Y dado que en el "viejo mundo en cascada" las pruebas se realizan después de la implementación, esta mentalidad conduce a una comprensión y un comportamiento incorrectos.

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

Answer 3

Parece haber dos tipos de BDD.

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

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

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

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

Answer 4

Desarrollo basado en pruebas es una metodología de desarrollo de software que prioriza la prueba, lo que significa que requiere escribir código de prueba antes de escribir el código real que se probará.En palabras de Kent Beck:

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

Después de averiguar cómo escribir un pequeño código, ahora, en lugar de solo codificar, queremos obtener comentarios inmediatos y practicar "código un poco, probar un poco, codificar un poco, probar un poco". Así que inmediatamente escribimos una prueba para ella.

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

Desarrollo impulsado por el comportamiento es una metodología que se creó en base a TDD, pero que evolucionó hasta convertirse en un proceso que no concierne solo a programadores y evaluadores, sino que trata con todo el equipo y todas las partes interesadas importantes, técnicas y no técnicas.BDD comenzó con algunas preguntas simples que TDD no responde bien:¿Cuántas pruebas debo escribir?¿Qué debería probar realmente y qué no?¿Cuáles de las pruebas que escribo serán realmente importantes para el negocio o para la calidad general del producto y cuáles son simplemente mi exceso de ingeniería?

Como puede ver, estas preguntas requieren la colaboración entre la tecnología y las empresas.Las partes interesadas del negocio y los expertos en el campo a menudo pueden decirles a los ingenieros qué tipo de pruebas parecen útiles, pero solo si las pruebas son de alto nivel y abordan aspectos comerciales importantes.BDD llama “ejemplos” a estas pruebas de tipo empresarial, como en “dígame un ejemplo de cómo debería comportarse correctamente esta característica” y reserva la palabra “prueba” para verificaciones técnicas de bajo nivel, como la validación de datos o las pruebas de integraciones de API.Lo importante es que mientras pruebas sólo puede ser creado por programadores y probadores, ejemplos puede ser recopilado y analizado por todo el equipo de entrega: por diseñadores, analistas, etc.

En una frase, una de las mejores definiciones de BDD que tengo. encontró Hasta ahora es que BDD se trata de "tener conversaciones con expertos en dominios 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, comienza a comprender cada vez más el ámbito empresarial y, por lo tanto, reduce su incertidumbre sobre algunos aspectos del producto con el 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 empezar a sugerir sus propios ejemplos que los usuarios empresariales no creían posibles debido a su falta de experiencia tecnológica.

Ahora, tener conversaciones con 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 codigo—algoritmos, patrones de diseño, abstracciones.O, si eres diseñador, te enseñan a diseño—Organizar información y crear hermosas interfaces.Pero cuando obtenemos 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 sabía casi nada sobre banca, excepto cómo reducir eficientemente el saldo de mi cuenta.Entonces 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 ofrecer 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 requisitos y le ayudará a aprender cómo crear un excelente proceso BDD y utilizar ejemplos como parte central de ese proceso.El libro habla sobre el lenguaje ubicuo, 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 software excelente a tiempo y dentro del presupuesto.

Si está interesado en comprar “Escribir excelentes especificaciones”, puedes ahorrar 39% con el código promocional 39nicieja2 :)

Answer 5

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

BDD también se utiliza como herramienta de comunicación.El objetivo es escribir especificaciones ejecutables que puedan ser entendidas por los expertos en el dominio.

Answer 6

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

Answer 7

Con mis últimos conocimientos sobre BDD en comparación con TDD, BDD se centra en especificar qué sucederá a continuación, mientras que TDD se centra en establecer un conjunto de condiciones y luego observar el resultado.

Answer 8

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

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

Desarrollo impulsado por el comportamiento

Aunque yo mismo no practico BDD.

Answer 9

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

Consideremos ahora una implementación popular de TDD: pruebas unitarias.Las unidades en las pruebas unitarias suelen ser un fragmento de lógica que es la unidad de trabajo más pequeña que puede realizar.

Cuando reúne esas Unidades de manera funcional para describir el Comportamiento deseado para las máquinas, necesita comprender el Comportamiento que le está describiendo a la máquina.El diseño basado en el comportamiento se centra 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.BDD bien hecho implica negocios y desarrollo (y control de calidad), 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.

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

Answer 10

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

BDD es más que "TDD bien hecho"

Answer 11

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 estar informado sobre el Dominio antes de cada ciclo de tocar el código!

• BDD es una implementación de TDD que incorpora algunos aspectos de DDD.

¡Espero que ayude!

Answer 12

Diferencia entre desarrollo impulsado por pruebas (TDD) y desarrollo impulsado por comportamiento (BDD)

• BDD se centra en el aspecto conductual del sistema más que en el
  aspecto de implementación del sistema en el que se centra TDD.

• BDD brinda una comprensión más clara de lo que debe hacer el sistema
  desde la perspectiva del desarrollador y del cliente.solo TDD
  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 en el análisis de requisitos que está contenido dentro del código fuente del sistema.

Answer 13

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 con las que escribe las pruebas BDD, puede venir de su cliente con algunas de sus pruebas definidas y listas para escribir código.