Desarrollo impulsado por el comportamiento

El desarrollo dirigido por el comportamiento ( BDD ) es un método ágil de desarrollo de software centrado en la colaboración entre profesionales de negocios y de TI que tienen interés en encontrar una solución para un problema complejo. El objetivo principal es lograr una comprensión compartida del problema. ^{[ 1 ]}

BDD implica el uso de un lenguaje específico de dominio (DSL) que utiliza construcciones del lenguaje natural (por ejemplo, oraciones similares al inglés) que pueden expresar el comportamiento y los resultados esperados. ^{[ 2 ]}

BDD fomenta la colaboración entre desarrolladores, expertos en control de calidad y representantes de clientes en un proyecto de software. ^{[ 3 ] [ 4 ]} Anima a los equipos a utilizar la conversación y ejemplos concretos para formalizar una comprensión compartida de cómo debería comportarse la aplicación. ^{[ 5 ]} BDD se considera una práctica eficaz, especialmente cuando el espacio del problema es complejo. ^{[ 6 ]}

Una idea errónea común sobre BDD es que supuestamente es un refinamiento del desarrollo guiado por pruebas (TDD). Si bien se derivó originalmente de las prácticas de TDD, ^{[ 7 ]} el único propósito de BDD es obtener una comprensión compartida del espacio del problema y encontrar una manera de escribirlo en un lenguaje empresarial, utilizando datos reales, a la vez que sea revelador de intenciones, esencial y enfocado (BRIEF). ^{[ 8 ]} BDD combina las técnicas de TDD con ideas del diseño dirigido por dominio y el análisis y diseño orientado a objetos para proporcionar a los equipos de desarrollo y gestión de software herramientas compartidas y un proceso compartido para colaborar en el desarrollo de software. ^{[ 3 ] [ 9 ]}

En términos generales, BDD es una idea sobre cómo se debe gestionar el desarrollo de software considerando tanto los intereses comerciales como la perspectiva técnica. Su práctica implica el uso de herramientas especializadas. ^{[ 10 ]} Algunas herramientas específicas para BDD se pueden utilizar para TDD. Estas herramientas automatizan el lenguaje ubicuo .

BDD es un proceso mediante el cual las declaraciones en lenguaje natural estructuradas en DSL se convierten en pruebas ejecutables. El resultado es una especificación ejecutable que, con el tiempo, conforma la Documentación Viva: Requisitos que también son las primeras pruebas de aceptación que impulsan el desarrollo del software ( Desarrollo guiado por pruebas de aceptación ).

BDD se centra en:

• Colaboración entre personas del ámbito empresarial y técnico.
• Crear un entendimiento común del problema que hay que resolver y cómo resolverlo (sin incluir aún detalles sobre la implementación técnica elegida).
• Escribir esto de forma inequívoca y precisa para que pueda convertirse en especificaciones ejecutables ^{[ 11 ].}

A partir de este punto, muchas personas desarrollaron marcos BDD durante varios años, finalmente enmarcándolo en términos de un marco de comunicación y colaboración para desarrolladores, control de calidad y participantes no técnicos o comerciales en un proyecto de software. ^{[ 12 ]}

BDD sugiere que las pruebas de software deben nombrarse en términos del comportamiento deseado . ^{[ 10 ] [ 9 ]} Tomando prestado del desarrollo ágil de software, el "comportamiento deseado" en este caso consiste en los requisitos establecidos por el negocio , es decir, el comportamiento deseado que tiene valor comercial para la entidad que encargó la unidad de software en construcción. ^{[ 10 ]} Dentro de la práctica de BDD, esto se conoce como BDD como una actividad "de afuera hacia adentro".

TDD no diferencia las pruebas en función de los requisitos de software de alto nivel, los detalles técnicos de bajo nivel ni nada intermedio. Por lo tanto, una forma de ver BDD es como una evolución de TDD que toma decisiones más específicas.

Al igual que TDD, BDD puede implicar el uso de herramientas especializadas.

BDD requiere no solo código de prueba, como TDD, sino también un documento que describa el comportamiento en un lenguaje más comprensible para los humanos. Esto implica un proceso de dos pasos: ejecutar las pruebas, leer e interpretar las descripciones, y leer el código de prueba y encontrar la implementación correspondiente para ejecutar. Este proceso hace que BDD sea más laborioso para los desarrolladores. Sus defensores sugieren que, debido a su naturaleza comprensible para los humanos, el valor de estos documentos se extiende a un público relativamente no técnico y, por lo tanto, pueden servir como medio de comunicación para describir los requisitos ("características").

Una subcategoría aparte del desarrollo dirigido por el comportamiento la constituyen las herramientas que utilizan especificaciones como lenguaje de entrada en lugar de historias de usuario. Las herramientas de especificación no utilizan historias de usuario como formato de entrada para los escenarios de prueba , sino que emplean especificaciones funcionales para las unidades que se están probando. Estas especificaciones suelen tener un carácter más técnico que las historias de usuario y, por lo general, resultan menos convenientes para la comunicación con el personal de negocio. ^{[ 10 ] [ 19 ]} Un ejemplo de especificación para una pila podría ser el siguiente:

Especificación: Pila Cuando se crea una nueva pila, entonces está vacía. Cuando se agrega un elemento a la pila , ese elemento se coloca en la parte superior de la pila. Cuando una pila tiene N elementos y el elemento E está en la parte superior de la pila, entonces una operación pop devuelve E y el nuevo tamaño de la pila es N-1.

Dicha especificación puede describir con exactitud el comportamiento del componente que se está probando, pero resulta menos significativa para un usuario de negocio. Por consiguiente, en la práctica de BDD, las pruebas basadas en especificaciones se consideran un complemento de las pruebas basadas en historias y operan a un nivel inferior. A menudo, las pruebas de especificación se ven como un sustituto de las pruebas unitarias de formato libre. ^{[ 19 ]}

La reunión de los "tres amigos", también conocida como "Taller de Especificación", es una reunión donde el propietario del producto discute los requisitos en forma de especificación mediante ejemplos con diferentes partes interesadas, como el equipo de control de calidad y el equipo de desarrollo. El objetivo principal de esta discusión es iniciar el diálogo e identificar cualquier especificación faltante. La discusión también proporciona una plataforma para que el equipo de control de calidad, el equipo de desarrollo y el propietario del producto converjan y escuchen las perspectivas de cada uno para enriquecer los requisitos y asegurarse de que están construyendo el producto correcto. ^{[ 20 ]}

Los tres amigos son:

• Negocio - El rol del usuario de negocio es definir el problema únicamente y no aventurarse a sugerir una solución.
• Desarrollo - El rol de los desarrolladores implica sugerir formas de solucionar el problema.
• Pruebas: La función de los evaluadores es cuestionar la solución, plantear tantas posibilidades diferentes como sea posible para generar ideas a través de escenarios hipotéticos y ayudar a que la solución sea más precisa para solucionar el problema.

• Desarrollo basado en especificaciones
• Especificación mediante ejemplo
• Behat (marco de trabajo PHP)
• Marco de trabajo Cynefin
• Concordion (framework de Java)
• Especificación R
• Indicador
• Jasmine (marco de pruebas de JavaScript)
• Probador de interfaz gráfica Squish (Herramienta de prueba de interfaz gráfica BDD para JavaScript, Python, Perl, Ruby y Tcl)
• Caso de uso
• Fitnesse se ha utilizado para implementar BDD ^{[ 21 ]}
• Pepino (software)