Me pregunto si BDD es un reemplazo de TDD? Lo que entiendo ahora es que en un último BDD ya no tenemos pruebas unitarias. En cambio, hay historias/escenarios/características y "pasos de prueba". Y parece un reemplazo completo de TDD para mí. TDD está muerto?¿El BDD es un reemplazo de TDD?
No, en absoluto. BDD es solo una variante de TDD.
En TDD, usted formula sus requisitos como una prueba ejecutable y luego escribe el código de producción para completar la prueba. BDD no hace más que volver a formular estos requisitos en una forma más legible para los humanos y, por lo tanto, hace que las pruebas sean algo más detalladas para un lector humano que observa el informe de la prueba. (Por cierto: para lograr esto, BDD requiere mucho más código que las pruebas unitarias tradicionales basadas en datos ...)
Eso es todo.
Thomas
BDD * en un nivel de escenario * requiere más código que la prueba unitaria. A nivel de pruebas unitarias, puede ser mucho más conciso, ya que el lenguaje te ayuda a eliminar la duplicación y enfocarte en el comportamiento que realmente te interesa. Ofrezco ejemplos de esto, en un nivel de escenario: http://code.google. com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs y a nivel de unidad: http://code.google.com/p/wipflash/source/browse/WiPFlash.Behavior/Framework/WaiterBehaviour .cs – Lunivore
que tienen un punto de vista diferente en esto que otros respondedores.
Dan North creó BDD druing su trabajo de consultoría en TDD cuando vio que muchas personas estaban confundidas por la parte de "prueba", porque tenían experiencia en pruebas, decidió cambiar el nombre. Entonces, al principio, BDD era exactamente lo que es TDD, explicado correctamente. Después de eso, Dan comenzó a extender la idea de usar especificaciones ejecutables (pruebas unitarias) para impulsar las implementaciones al agregar otros niveles de especificación. Se inspiró en las historias de usuarios, por lo que el BDD más simple implementado por la mayoría de las herramientas le permite escribir requisitos como escenarios de historias de usuario, que escribir código que genera pruebas de unidad y que a partir de esas pruebas de unidad que trabaja en la implementación. Entonces, ahora ves en comparación con TDD, hay otro nivel de especificación: historias de usuarios. Muchas herramientas incluyen traducciones preparadas de historias de usuario a pruebas, por lo que muchas se olvidan de ellas como lo hizo, pero todavía están allí y no se pueden omitir por completo. Prácticamente, y también teóricamente, la programación de historias de usuarios no es eficiente. Pero ese no es el punto, usted usa historias de usuarios para reunir los requisitos de las partes interesadas y para demostrar que las implementó mediante la ejecución de pruebas de aceptación.
Hay muchas otras cosas pequeñas en BDD, es mejor leer el blog Dans para entenderlas, pero el punto principal es que BDD es una extensión de TDD incluso fuera de la fase de implementación, por lo que no pueden ser intercambiadas o inutilizadas otro.
Gabriel está casi en lo cierto.
La diferencia fundamental a nivel de unidad es que BDD utiliza la palabra "debería" en lugar de "prueba". Resulta que cuando dices "prueba", la mayoría de la gente comienza a pensar sobre lo que hace su código, y cómo pueden probarlo. Con BDD, consideramos y cuestionamos qué debería hacer nuestro código . Es un punto sutil pero importante, y si quieres saber por qué es tan poderoso, lee la Programación Neurolingüística, particularmente sobre la forma en que las palabras afectan los pensamientos y el modelo del mundo. Como un breve ejemplo, muchas personas que son nuevas en TDD comienzan a fijar su código para que nadie pueda romperlo. Los BDD tienden a proporcionar ejemplos que demuestran el valor de su código para que las personas puedan cambiar su código de forma segura.
Dan se dio cuenta mientras hablaba con Chris Matts y escribió JBehave que podía llevar esto a un nivel de escenario (los escenarios no son lo mismo que las historias). Debido a que ya estábamos usando "debería" a nivel de unidad, tenía sentido comenzar a escribir cosas en inglés (tiendo a usar "debería darme" en lugar de "debería volver", por ejemplo). El desarrollo impulsado por la prueba de aceptación (ATDD, por sus siglas en inglés) ha existido durante mucho tiempo, pero fue AFAIK la primera vez que alguien los había escrito en inglés con las partes interesadas de la empresa involucradas.
Es más que un reemplazo para TDD. Es una forma diferente de pensar sobre las pruebas, muy centrada en el aprendizaje, descubriendo deliberadamente áreas en las que tal vez pensamos que sabíamos lo que estábamos haciendo pero no lo hicimos, descubriéndonos y ayudándonos a resolver la ignorancia y la incomprensión. Funciona en muchos niveles. La función de inyección de Chris Matts lleva esto al espacio de nivel superior, justo en el camino hacia la visión del proyecto.
Aún escribimos ejemplos, o especificaciones si lo desea, a nivel de unidad también, pero en realidad, es un patrón que va mucho más allá de los escenarios. Si quiere saber más, might find my blog useful, Dan's is even better. Además, Chris has a comic book on Real Options que describe algunos de los patrones que he mencionado.
BDD no se trata de reemplazar TDD. Se trata de dar un poco más de estructura y deciplene a sus prácticas de TDD. Lo más difícil de TDD es que los desarrolladores sin una imagen más amplia apenas tienen idea de qué probar y cuánto probar. BDD proporciona una guía muy concreta con esta área gris. Echa un vistazo a este post,
http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/
Por lo que yo entiendo las ventajas de BDD sobre TDD son:
Todo lo demás va de la misma manera que normalmente con TDD. De modo que puede usar cualquier lib de aserción en las definiciones de paso que usaría en las pruebas unitarias. La única diferencia es que agregó otro nivel de abstracción al separar qué (descripción de la función en pepinillo) de cómo (definiciones de paso en un lenguaje de programación) en su código de prueba.
Puede utilizar el término "Specification by Example" para BDD, que enfatiza un aspecto importante de esta metodología: Especificar en colaboración - a través de talleres de especificación para todo el equipo, reuniones más pequeñas o revisiones de teleconferencia. Dentro de estas sesiones con diferentes partes interesadas, se usan ejemplos concretos para ilustrar los requisitos. Discutir los requisitos en forma de ejemplos ayuda a crear una comprensión compartida del dominio del problema y las posibles soluciones.
Por accidente, las especificaciones con ejemplos son adecuadas para la automatización de pruebas. Como resultado, generalmente mejora la cobertura de la prueba. Pero esta metodología también ayuda a involve non-technical stakeholders. Las herramientas que lo ayudan create business readable input no están relacionadas, por naturaleza, con los lenguajes de programación, pero a menudo se basan en simple document formats que son fácilmente comprensibles para muchas personas.
BDD debe enfatizar el comportamiento desde la perspectiva del usuario y es ideal para conducir pruebas de extremo a extremo, una especie de DSL de personas pobres para el desarrollo impulsado por pruebas de aceptación. Puede complementar TDD pero definitivamente no es un sustituto. TDD es tanto una actividad de diseño como una actividad de prueba (el código que está mal diseñado es difícil de probar, las pruebas unitarias fomentan un buen diseño). BDD no tiene nada que ver con el diseño. Es un tipo de prueba que se abstrae completamente del código.
En la práctica, BDD da como resultado mucho más código de placa de caldera bajo el capó que las pruebas de aceptación normales, por lo tanto prefiero crear una DSL interna en un lenguaje de programación normal para conducir mis pruebas de aceptación. En cuanto a las pruebas unitarias, BDD enfatiza el comportamiento desde la perspectiva del usuario y, por lo tanto, no debe usarse a nivel de unidad.
BDD es un intento de cerrar la brecha de comunicación entre los accionistas interesados y los programadores. En algunas áreas puede ser útil, como aplicaciones bancarias donde la atención al detalle en cosas como los cálculos de la tasa de interés es importante, y requiere la participación directa de expertos en el dominio. IMHO BDD no es la panacea que algunos de sus acólitos afirman que es y solo debe usarse si hay una razón convincente para hacerlo.
No realmente. BDD * extiende * TDD - si entiendo correctamente, uno de los puntos principales es permitir que los no programadores participen mejor en TDD. Las pruebas aún deben codificarse en algún momento, pero debería aclararse cuál es el * propósito * de las pruebas (en oposición a la mera * función *). – Piskvor
Incluso en el artículo de Wikipedia que vinculó, dicen: [BDD] extiende TDD escribiendo casos de prueba en un lenguaje natural que los no programadores pueden leer. – Grzenio