test qué metodología ejemplo atdd testing tdd bdd

testing - qué - Diferencias TDD y BDD



qué es bdd y tdd (9)

Honestamente, no veo la diferencia entre BDD y TDD. Quiero decir, ambas son solo pruebas si sucede lo que se espera. He visto Pruebas BDD que están tan desarrolladas que prácticamente cuentan como pruebas TDD, y he visto pruebas TDD que son tan vagas que hacen que aparezcan muchos códigos en negro. Digamos que estoy bastante convencido de que tener ambas cosas es mejor.

Aquí hay una pregunta divertida. ¿Dónde empiezo? ¿Comienzo con pruebas BDD de alto nivel? ¿Comienzo con pruebas de TDD de bajo nivel?

Honestamente, no veo la diferencia entre BDD y TDD.

Eso es porque no hay ninguno.

Quiero decir, ambas son solo pruebas si sucede lo que se espera.

Eso está mal. BDD y TDD no tienen absolutamente nada que ver con las pruebas. Ninguna. Nada. Zilch. Cremallera. Nada. En lo mas minimo.

Desafortunadamente, TDD tiene la palabra "prueba" en casi todo (no solo en su nombre, sino también en el marco de prueba, prueba de unidad, TestCase (la clase heredada típicamente), FooTest (la clase que normalmente contiene sus pruebas), testBar (el patrón de nomenclatura típico para un método de prueba), además de una terminología relacionada con pruebas de lotes como "afirmación" y "verificación") que hace que algunas personas crean que realmente tiene algo que ver con las pruebas. Entonces, algunas personas inteligentes dijeron: "Oye, cambiemos el nombre" para eliminar cualquier posibilidad de confusión.

Y eso es lo que es BDD. Es solo TDD con cualquier terminología relacionada con pruebas reemplazada por terminología relacionada con ejemplos de comportamiento:

  • Prueba → Ejemplo
  • Afirmación → Expectativa
  • assert → should
  • Unidad → Comportamiento
  • Verificación → Especificación
  • … y así

BDD es solo TDD con diferentes palabras. Si haces TDD bien, estás haciendo BDD. La diferencia es que, siempre que creas al menos en la forma débil de la Hipótesis de Sapir-Whorf, las diferentes palabras hacen que sea más fácil hacerlo bien.

BDD es desde el punto de vista de los clientes y se centra en el comportamiento excitado de todo el sistema.

TDD es desde el punto de vista de los desarrolladores y se centra en la implementación de una unidad / clase / función. Se beneficia, entre otros, de una mejor arquitectura (diseño para la capacidad de prueba, menos acoplamiento entre módulos).

Desde el punto de vista técnico (cómo escribir la "prueba") son similares.

Yo (desde un punto de vista ágil ) comenzaría con un bdd-userstory y lo implementaría usando TDD.

Creo que la mayor contribución de BDD sobre TDD o cualquier otro enfoque, es hacer que las personas no técnicas (propietarios / clientes de productos) sean parte del proceso de desarrollo de software en todos los niveles.

Escribir escenarios ejecutables en lenguajes naturales casi ha salvado la brecha entre el requisito y la entrega.

Los propietarios del producto pueden ejecutar los escenarios que ha escrito y probar con diferentes conjuntos de datos si quiere jugar con el comportamiento del código escrito por el equipo de desarrollo.

¡Eso es increíble! El cliente está sentado justo en el centro y, precisamente, no solo pregunta qué es lo que realmente quiere, sino que también verifica y experimenta los entregables.

La principal diferencia es solo la redacción. BDD usa un estilo más detallado para que pueda leerse casi como una oración.

La terminología es diferente, pero en mi trabajo, utilizo TDD para desarrollar detalles, principalmente para pruebas unitarias, y el BDD es de más alto nivel, para clientes, control de calidad o para personas sin conocimientos técnicos.

Según lo que he reunido en Wikipedia, BDD incluye la aceptación y la prueba de QA que no se puede hacer sin la participación de los interesados ​​/ usuarios. También BDD usa un lenguaje natural para especificar su prueba, mientras que TDD usualmente usa lenguaje de programación. Puede haber cierta superposición entre los dos pero creo que no es la vaguedad sino el lenguaje de BDD la principal diferencia.

En cuanto a dónde comenzarás, bueno eso realmente depende de tu proceso de desarrollo, ¿verdad? Supongo que si estás haciendo bottom-up, primero escribirás TDD y una vez que alcances un nivel superior, usarás BDD para probar si esas características funcionan como se espera.

Como señaló k3b, la principal diferencia sería que BDD está orientado al dominio del problema, mientras que TDD está más orientado al dominio de la solución.

Simplemente copié la respuesta de Matthew Flynn, y estoy más de acuerdo en que "TDD y BDD no tienen nada que ver con las pruebas":

Behavior Driven Development es una extensión / revisión de Test Driven Development. Su propósito es ayudar a las personas que diseñan el sistema (es decir, los desarrolladores) a identificar las pruebas adecuadas para escribir, es decir, las pruebas que reflejan el comportamiento deseado por los interesados. El efecto termina siendo el mismo: desarrolla la prueba y luego desarrolla el código / sistema que pasa la prueba. La esperanza en BDD es que las pruebas sean realmente útiles para demostrar que el sistema cumple con los requisitos.

ACTUALIZAR

Las unidades de código (métodos individuales) pueden ser demasiado granulares para representar el comportamiento representado por las pruebas de comportamiento, pero aún debe probarlas con pruebas unitarias para garantizar que funcionen correctamente. Si esto es lo que quiere decir con las pruebas "TDD", entonces sí, todavía las necesita.