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

votos
119

Test Driven Development ha sido la furia en la comunidad .NET durante los últimos años. Recientemente, he escuchado refunfuños en la comunidad ALT.NET sobre BDD. ¿Qué es? ¿Qué lo hace diferente de TDD?

Publicado el 05/08/2008 a las 16:58
fuente por usuario
En otros idiomas...                            


15 respuestas

votos
94

Entiendo que BDD tiene más que ver con las especificaciones que con las pruebas . Está vinculado al Diseño Dirigido por el Dominio (¿no te encantan estos * acrónimos DD?).

Está relacionado con una cierta forma de escribir historias de usuario, 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 pasa a ejecutar directamente esta especificación de prueba en Ruby).

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

Encontrarás 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 una reciente por Llewellyn Falco, BDD vs TDD (explicado) . Encuentro su explicación clara y directa.

Respondida el 05/08/2008 a las 17:36
fuente por usuario

votos
17

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

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

BDD dirige el enfoque en el comportamiento y las especificaciones, por lo que las mentes en cascada se distraen. Entonces BDD se entiende más fácilmente como práctica de diseño y no como práctica de prueba.

Respondida el 08/09/2008 a las 19:36
fuente por usuario

votos
13

Parece que hay dos tipos de BDD.

El primero es el estilo original que Dan North discute 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 lo 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 las clases de prueba pequeñas, tratando de llegar al punto donde 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 hacer utilizando cualquier marco de prueba de unidades existente, aunque los marcos más nuevos (estilo xSpec) ayudan a enfocar el comportamiento en lugar de las pruebas.

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

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

Respondida el 10/09/2008 a las 17:00
fuente por usuario

votos
6

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 se mueve en ese nivel.

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

Respondida el 27/08/2008 a las 21:59
fuente por usuario

votos
5

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

El estilo aquí es escribir unas pocas líneas de código, a continuación, una prueba que se debe ejecutar, o mejor aún, escribir una prueba de que no va a funcionar, a continuación, escribir el código que va a hacer que se ejecute.

Después de encontrar la manera de escribir una pequeña pieza de código, ahora, en lugar de la codificación en adelante, queremos obtener una respuesta inmediata y práctica "código un poco, probar un poco, un poco de código, probar un poco." Por lo que de inmediato escribir una prueba para él.

Así TDD es un nivel bajo, metodología técnica que los programadores utilizan para producir un código limpio que funciona.

Desarrollo comportamiento-Driven es una metodología que se ha creado sobre la base de TDD, pero se convirtió en un proceso que no sólo se refieren a los programadores y probadores, sino que se ocupa de todo el equipo y todos los actores importantes, técnica y no técnica. BDD comenzó de una serie de preguntas sencillas que TDD no contesta así: la cantidad de pruebas debo escribir? Lo que en realidad debería probar-y lo que no debería? ¿Cuál de las pruebas que escribo será de hecho importante para el negocio o para la calidad general del producto, y que son sólo mi exceso de ingeniería?

Como se puede ver, estas cuestiones requieren la colaboración entre la tecnología y los negocios. Los actores empresariales y expertos en el dominio frecuencia ingenieros pueden decir qué tipo de pruebas suenan como si serían pruebas, pero útil sólo si las pruebas son de alto nivel que se ocupan de los aspectos importantes del negocio. BDD llama a estos “ejemplos”, pruebas de tipo empresarial como en “dime un ejemplo de cómo esta función debe comportarse correctamente”, y se reserva la palabra “prueba” de bajo nivel, controles técnicos, como la validación de datos o integraciones de API de pruebas. La parte importante es que mientras que las pruebas sólo pueden ser creados por programadores y probadores, ejemplos pueden ser recogidos y analizados por el entero de entrega diseñadores equipo por, analistas, y así sucesivamente.

En una frase, una de las mejores definiciones de BDD que he encontrado hasta ahora es que el TDC se trata de “tener conversaciones con expertos en el dominio y el uso de ejemplos para obtener una comprensión compartida de la conducta deseada y descubrir incógnitas.” La parte descubrimiento es muy importante . A medida que el equipo de entrega recoge más ejemplos, empiezan a entender el dominio de negocio cada vez más y por lo tanto reducen su incertidumbre acerca de algunos aspectos del producto que tienen que tratar. A medida que disminuye la incertidumbre, la creatividad y la autonomía del incremento equipo de entrega. Por ejemplo, ahora pueden empezar a sugerir sus propios ejemplos de que los usuarios de negocios no pensaron eran posibles debido a su falta de experiencia en tecnología.

Ahora, tener conversaciones con los expertos en negocios y dominio suena muy bien, pero todos sabemos lo que a menudo termina en la práctica. Empecé mi viaje con tecnología como programador. Como programadores, se nos enseña a escribir código -algorithms, patrones de diseño, abstracciones. O, si usted es un diseñador, que se les enseña a diseñar-Organizar la información y crear hermosas interfaces. Pero cuando llegamos a nuestros puestos de trabajo de nivel de entrada, los empleadores esperan que "entregar valor a los clientes." Y entre aquellos clientes pueden ser, por ejemplo ... un banco. Pero podría saber casi nada acerca de la banca, excepto cómo disminuir eficazmente el saldo de mi cuenta. Así que 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 entregar cualquier valor. BDD ayuda a construir ese puente sobre una base estable de comunicación fluida entre el equipo de entrega y los expertos de dominio.

Aprende más

Si desea leer más acerca de BDD, escribí un libro sobre el tema. “Escribir Grandes Especificaciones” explora el arte del análisis de las necesidades y le ayudará a aprender cómo construir un gran proceso de BDD y utilizar los ejemplos como parte central de ese proceso. El libro habla de la lengua en todas partes, recogiendo ejemplos, y la creación de los llamados especificaciones ejecutables (pruebas automatizadas) fuera de los ejemplos de técnicas que ayudan a los equipos TDC entregan gran softeware a tiempo y dentro del presupuesto.

Si usted está interesado en comprar “escribir grandes Especificaciones”, se puede ahorrar un 39% con el código promocional 39nicieja2 :)

Respondida el 12/02/2017 a las 13:43
fuente por usuario

votos
2

Considere el principal beneficio de TDD a ser el diseño. Debería llamarse Diseño Test Driven. BDD es un subconjunto de TDD, llame a su comportamiento Driven Design.

Consideremos ahora una aplicación popular de TDD - Unidad de Pruebas. Las unidades en las pruebas unitarias son típicamente uno poco de lógica que es la unidad más pequeña de trabajo que puede hacer.

Cuando se pone esas unidades juntas de una manera funcional para describir el comportamiento deseado de las máquinas, es necesario comprender el comportamiento que usted está describiendo a la máquina. Comportamiento determinadas por el diseño se centra en la verificación de la comprensión de los ejecutores del empleo Casos / Requisitos / Lo y verifica la ejecución de cada función. TDC y TDD, en general, tiene el propósito de informar importante del diseño y el segundo fin de verificar la exactitud de la aplicación, especialmente cuando cambia. BDD hecho implica la derecha y biz dev (y QA), mientras que las pruebas unitarias (posiblemente de forma incorrecta visto como TDD en lugar de un tipo de TDD) se realiza normalmente en el silo prog.

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

Respondida el 28/05/2015 a las 22:36
fuente por usuario

votos
2

BDD es en gran parte TDD se haga bien. Sin embargo, hay un valor adicional que el TDC ofrece. Aquí hay un enlace en el que:

BDD es más que “la derecha TDD hecho”

Respondida el 29/07/2010 a las 11:25
fuente por usuario

votos
2

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

Respondida el 25/05/2009 a las 05:09
fuente por usuario

votos
2

Me parece que BDD tiene un alcance más amplio. Casi implica que se usa TDD, que BDD es la metodología abarcadora 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.

Respondida el 05/08/2008 a las 17:11
fuente por usuario

votos
2

El desarrollo impulsado por el comportamiento parece centrarse más en la interacción y la 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

Aunque no practico BDD.

Respondida el 05/08/2008 a las 17:06
fuente por usuario

votos
1

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

  • BDD se centra en el aspecto del comportamiento del sistema en lugar del
    aspecto implementación del sistema que se centra en TDD.

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

  • BDD permite que tanto el desarrollador y el cliente de trabajar juntos para sobre los requisitos de análisis que está contenida dentro del código fuente del sistema.

Respondida el 09/06/2017 a las 20:49
fuente por usuario

votos
1

Aquí está el panorama:

  • TDD es sólo el proceso de código de prueba antes de escribirlo!

  • DDD es el proceso de ser informados sobre el dominio antes de cada ciclo de tocar el código!

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

¡Espero que ayude!

Respondida el 18/01/2016 a las 00:01
fuente por usuario

votos
0

La elección entre TDD y BDD es un tema complejo. Depende de si hay un marco de pruebas apropiado para su idioma determinado objetivo, lo que sus compañeros de trabajo se sienten cómodos con, y algunas veces otros factores.

Algunos argumentan que el TDC es siempre mejor que TDD, ya que tiene la posibilidad de eliminar los problemas que puedan surgir al utilizar TDD.

La clave para BDD es que podría evitar problemas; no se garantiza a. Cuestiones como la mala organización del código, malas prácticas de diseño, etc. todavía persistirán. Usted acaba de tener un menor campana probable de escribir malas pruebas y por lo tanto tienen características más robustas.

Respondida el 18/09/2016 a las 06:59
fuente por usuario

votos
0

No hay diferencia Transcurrirá TDD y BDD. excepto en que puede leer sus mejores pruebas, y se puede utilizar como requisitos. Si usted escribe sus necesidades con las mismas palabras a medida que escribe pruebas TDC, entonces puede venir Frome su cliente con algunos de sus ensayos definidos listo para escribir código.

Respondida el 07/10/2014 a las 09:52
fuente por usuario

votos
-1

Este blog ofrece un punto de vista interesante sobre las diferencias entre TDD, BDD, y ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/

Respondida el 20/05/2014 a las 19:32
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more