¿El desarrollo impulsado por el comportamiento es sobre diseño o análisis?

Question

Cuanto más leo sobre BDD y cómo se supone que se debe mejorar TDD, más confuso me parece. He encontrado citas de expertos que dicen que se trata de diseño, pero también de otros expertos que dicen que se trata de análisis.

La forma en que lo veo actualmente es esta:

1) análisis: BDD

de wikipedia

  

El resultado del análisis orientado a objetos   Es una descripción de lo que es el sistema.   Funcionalmente requerido para hacer, en el   Forma de un modelo conceptual.

Luego de la BDD tenemos los requisitos (historias y escenarios). Pero no estoy seguro de la parte del modelo conceptual.

2) diseño: por ejemplo, con herramientas como el diseño basado en la resonsibilidad utilizando tarjetas CRC

3) código: codificando el diseño, opcionalmente use pruebas (como lo que dicen sobre TDD hecho mal, lo que también me parece útil)

¿Estoy equivocado en cómo veo esto? Estoy teniendo problemas para ver el bosque a través de los árboles en este momento.

Answer 1

En resumen, tiene que ver con Análisis .

BDD es para " desarrollo basado en pruebas de aceptación " - es decir, para saber si un sistema bajo prueba se comporta como se espera para un escenario de historia de usuario específico.

Cuando trabajé con Jbehave lo usamos en el nivel de historia de usuario y aún lo hicimos "convencional" TDD para manejar colaboraciones entre objetos individuales y entre subsistemas.

Normalmente, los sistemas de negocios usan escenarios de BDD para describir el comportamiento del dominio de negocios, no para probar los pequeños detalles de implementación dentro del sistema. Desea que los escenarios de BDD se realicen al nivel de abstracción del experto en dominios. Esos escenarios no tendrían mucho sentido para los expertos en dominios y serían muy frágiles si describieran cada pequeño detalle de la implementación.

Un escenario de BDD dice lo que debe hacer el sistema por una historia de usuario pero no cómo lo hace.

Answer 2

BDD se trata de escribir " especificaciones ejecutables " o prueba de aceptación también conocida como prueba de caja negra que, por definición, toma una Perspectiva externa del objeto de prueba para derivar casos de prueba .

Por lo tanto, la BDD no puede tener que ver con el diseño, la BDD se trata de probar las características / historias / scenarii, la BDD está más cerca del análisis.

Answer 3

BDD - Behavior Driven Development

Comportamiento = ..en el contexto de .. Desarrollo - ... en la construcción de ...

El desarrollo en este caso me indica que el análisis se ha realizado y uno está implementando algo que está en el contexto de un comportamiento específico.

para responder a la pregunta, creo que está en el Diseño .

Answer 4

Creo que desde una arquitectura POV BDD se trataría de diseño. Necesito diseñar una aplicación que pueda hacer algo, que luego se usará en las pruebas de aceptación. Por lo tanto, desde el diseño de alto nivel, quiero asegurarme de que estoy diseñando para los diversos requisitos de comportamiento, de modo que no esté diseñando en exceso y limite la duplicación.

Ayuda a garantizar que no sea necesario rediseñar, ya que el usuario tiene más tiempo para pensar qué es lo que realmente quiere ver y cómo se realizará la aplicación.

Answer 5

BDD (o TDD para el caso) no es sobre nada. Es una técnica (en el caso de BDD, más de un enfoque) que admite el diseño de análisis y (así como también ese molesto paso de implementación). A menudo escuchas la frase " rojo, verde, refactor " asociado con TDD, y por lo tanto se aplica a BDD: cree la prueba y vea que falla, haga que la prueba pase actualizando el código base, luego vuelva a trabajar el sistema en una forma mejorada mientras preserva las pruebas que pasan.

Por lo tanto, BDD admite el análisis al crear las pruebas: debe describir el comportamiento requerido en forma de pruebas o ejemplos. Es compatible con el diseño cuando ejecuta las pruebas: se evita que sus decisiones de diseño rompan inadvertidamente el comportamiento requerido y pueden ser guiadas por el análisis. Pero no hace ninguno de los análisis o diseño para usted; todavía tienes que pensar Es una forma de asegurarse de que, durante los pasos de análisis y diseño, no se contradiga.

Answer 6

BDD y TDD aún tienen un nombre muy desafortunado porque en realidad no cubre para qué se usan.

• No desea escribir pruebas para cada posible caso de esquina durante su ciclo de desarrollo, es algo que los evaluadores deben resolver.
• No desea regresiones y desea asegurarse de que está escribiendo el código que necesita para borrar esta iteración para que desee un resultado repetible
• No tiene que hacer diseños detallados al comienzo, sino anotar algunos requisitos que desea ver finalizados esta vez.

BDD / TDD cualquiera de los 2 está bien si no escribe una línea de código antes de tener un poco de código que describa el bit de código que está a punto de escribir. Haciendo eso entrarás en una zona.
Si bien no hay pruebas de que BDD / TDD mejore su velocidad de desarrollo (lo más probable es que no), reducirá en gran medida la cantidad de problemas que recupera después de lanzar el software que se ha probado.

BDD es una evolución de TDD donde TDD ejerce presión para probar todo lo que BDD relaja y dice que solo debes probar el comportamiento público de tus clases porque es probable que los aspectos internos cambien.

BDD tiene tanto que ver con el diseño como con el análisis, pero no creo que esa sea tu pregunta, ¿verdad? ¿Quieres saber cómo traducir las historias en diagramas de flujo y diagramas arquitectónicos?

Porque de lo que obtengo de tu pregunta es que haces un gran diseño desde el principio y luego tratas de codificar eso. Eso no funcionará con BDD porque al mismo tiempo que satisfaces tus historias, debes escribirlas de forma gradual para que obtengas tu código y tu arquitectura automáticamente. Se llama diseño emergente, por lo que no hay una gran fase de planificación.

En un sistema SCRUM o similar, esto funciona muy bien porque la empresa prioriza sus historias. Comienzas desde arriba y escribes una especificación / ejemplo para ello, luego intentas satisfacer el ejemplo repitiendo esto hasta que hayas completado este elemento de acumulación de pedidos y luego retomas el siguiente y comiences de nuevo.

Espero que esto responda a tu pregunta ... si no, necesitarás aclarar un poco porque es un tema valiente. En resumen, BDD es puramente una herramienta de desarrollo, no para arquitectos, licenciados, ... Los evaluadores pueden usar las herramientas BDD, pero espero que no sea la única herramienta que están usando para probar la aplicación.