Desarrollo impulsado por el comportamiento - Introducción
Behavior Driven Development (BDD) es un proceso de desarrollo de software que surgió originalmente de Test Driven Development (TDD).
Según Dan North, responsable de la evolución de BDD, "BDD está utilizando ejemplos en múltiples niveles para crear una comprensión compartida y la incertidumbre de la superficie para entregar software que importa".
BDD usa ejemplos para ilustrar el comportamiento del sistema que están escritos en un lenguaje legible y comprensible para todos los involucrados en el desarrollo. Estos ejemplos incluyen:
Convertido en especificaciones ejecutables.
Utilizado como pruebas de aceptación.
BDD: características clave
El desarrollo impulsado por el comportamiento se centra en:
Proporcionar un proceso compartido y herramientas compartidas que promuevan la comunicación con los desarrolladores de software, analistas de negocios y partes interesadas para colaborar en el desarrollo de software, con el objetivo de entregar un producto con valor comercial.
Qué debe hacer un sistema y no cómo debe implementarse.
Proporcionando mejor legibilidad y visibilidad.
Verificar no solo el funcionamiento del software, sino también que cumple con las expectativas del cliente.
Origen de BDD
El costo de reparar un defecto aumenta muchísimo si el defecto no se detecta en el momento adecuado y se repara cuando se detecta. Considere el siguiente ejemplo.
Esto muestra que, a menos que los requisitos se obtengan correctamente, sería costoso corregir los defectos resultantes de una mala comprensión de los requisitos en una etapa posterior. Además, es posible que el producto final no cumpla con las expectativas del cliente.
La necesidad del momento es un enfoque de desarrollo que:
Se basa en los requisitos.
Se centra en los requisitos durante todo el desarrollo.
Asegura que se cumplan los requisitos.
Un enfoque de desarrollo que puede hacerse cargo de los requisitos mencionados anteriormente es BDD. Por lo tanto, desarrollo impulsado por el comportamiento:
Deriva ejemplos de diferentes comportamientos esperados del sistema.
Permite escribir los ejemplos en un idioma utilizando los términos del dominio empresarial para garantizar una fácil comprensión por parte de todos los involucrados en el desarrollo, incluidos los clientes.
Consigue ratificar los ejemplos con el cliente de vez en cuando mediante conversaciones.
Se centra en los requisitos del cliente (ejemplos) durante todo el desarrollo.
Utiliza ejemplos como pruebas de aceptación.
Prácticas BDD
Las dos prácticas principales de BDD son:
Especificación por ejemplo (SbE)
Desarrollo basado en pruebas (TDD)
Especificación por ejemplo
Specification by Example (SbE) utiliza ejemplos en conversaciones para ilustrar las reglas comerciales y el comportamiento del software que se va a construir.
La especificación por ejemplo permite a los propietarios de productos, analistas comerciales, evaluadores y desarrolladores eliminar los malentendidos comunes sobre los requisitos comerciales.
Desarrollo basado en pruebas
Test Driven Development, en el contexto de BDD, convierte los ejemplos en especificaciones ejecutables y legibles por humanos.
Los desarrolladores utilizan estas especificaciones como guía para implementar incrementos de nuevas funciones. Esto da como resultado una base de código ajustada y un conjunto de pruebas de regresión automatizadas que mantienen bajos los costos de mantenimiento durante la vida útil del software.
BDD ágil
En el desarrollo de software ágil, el método BDD se utiliza para llegar a un entendimiento común sobre las especificaciones pendientes.
Los siguientes pasos se ejecutan en Agile BDD:
Los desarrolladores y el propietario del producto escriben en colaboración las especificaciones pendientes en un editor de texto sin formato.
El propietario del producto especifica los comportamientos que esperan del sistema.
Los desarrolladores
Complete las especificaciones con estos detalles de comportamiento.
Haga preguntas basadas en su comprensión del sistema.
Se consideran los comportamientos actuales del sistema para ver si la nueva función romperá alguna de las funciones existentes.
Manifiesto ágil y BDD
El Manifiesto Ágil establece lo siguiente:
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo, hemos llegado a valorar:
Individuals and interactions - sobre Procesos y herramientas
Working software - sobre documentación completa
Customer collaboration - sobre negociación de contrato
Responding to change - sobre Seguir un plan
Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.
BDD se alinea con el manifiesto Agile de la siguiente manera:
| Manifiesto ágil | Alineación BDD |
|---|---|
| Individuos e interacciones sobre procesos y herramientas. | BDD se trata de tener conversaciones. |
| Software de trabajo sobre documentación completa. | BDD se enfoca en facilitar la creación de software que sea de valor comercial. |
| Colaboración con el cliente sobre negociación de contratos. | BDD se enfoca en escenarios basados en ideas con comunicación continua con el cliente a medida que avanza el desarrollo. No se basa en promesas. |
| Responde al cambio sobre el siguiente plan. | BDD se centra en la comunicación y la colaboración continuas que facilitan la absorción de cambios. |