Behavior Driven Development
Behavior Driven Development, o BDD, conecta los requisitos del negocio con pruebas automatizadas. Los requisitos se describen en un lenguaje natural compartido que entienden por igual desarrolladores, testers y equipos de negocio. BDD reduce malentendidos y crea una visión común del comportamiento esperado.
En resumen
- BDD describe el comportamiento en lenguaje natural con el esquema Given-When-Then.
- Fomenta la colaboración entre el equipo de negocio, desarrollo y aseguramiento de calidad.
- Herramientas como Cucumber, SpecFlow o Behave traducen los escenarios en pruebas ejecutables.
- BDD no es un método de pruebas, sino una práctica de comunicación y desarrollo.
Descripción técnica compacta
BDD evolucionó a partir de TDD y se enfoca en el comportamiento del software desde la perspectiva empresarial. En lugar de formular técnicamente qué método debería devolver qué resultado, se describen ejemplos en el lenguaje de los usuarios. Estos ejemplos se convierten en pruebas que sirven simultáneamente como especificación y como documentación viva.
El esquema Given-When-Then
Given
Describe el estado inicial o la condición previa de un escenario.
When
Describe la acción que se ejecuta.
Then
Describe el resultado esperado o la reacción esperada.
Escenario de ejemplo
Escenario: Cliente recibe descuento en compra grande
Given un cliente tiene productos por valor de 200 euros en el carrito
When el cliente procede al pago
Then el importe total debe reducirse en 20 eurosHerramientas importantes
- Cucumber: Framework BDD popular para Java, Ruby, JavaScript y muchos otros lenguajes.
- SpecFlow: Framework BDD para .NET.
- Behave: Framework BDD para Python.
- Serenity BDD: Extensión para Cucumber enfocada en reporting.
- Gauge: Alternativa BDD ligera de ThoughtWorks.
Ejemplo práctico: Feature de Cucumber para un proceso de pedido
Feature: Cálculo de descuentos
Escenario: Descuento estándar a partir de 100 euros
Given el carrito contiene artículos por valor de 100 euros
When el cliente inicia el proceso de pedido
Then se aplica un descuento de 10 euros
And el nuevo importe total es de 90 euros
Escenario: Sin descuento por debajo de 100 euros
Given el carrito contiene artículos por valor de 50 euros
When el cliente inicia el proceso de pedido
Then no se aplica descuento
And el importe total es de 50 euros
Ventajas e inconvenientes
Ventajas
- Lenguaje compartido: El equipo de negocio y desarrollo hablan sobre los mismos ejemplos.
- Requisitos claros: Los malentendidos se detectan antes de la implementación.
- Documentación viva: Los escenarios describen el comportamiento del sistema de forma comprensible.
- Enfoque en valor: Las pruebas se orientan al valor empresarial, no a detalles técnicos.
Inconvenientes
- Esfuerzo: Crear y mantener escenarios requiere tiempo.
- Complejidad: Los archivos de features grandes pueden volverse difíciles de gestionar.
- Dependencia del equipo de negocio: Sin participación regular no se obtienen beneficios reales.
- Punto de quiebre técnico: Las definiciones de pasos mal mantenidas pueden generar problemas de mantenimiento.
Puntos clave para exámenes
- Definición y objetivo de BDD.
- El esquema Given-When-Then.
- Diferencia entre BDD y TDD.
- Rol del equipo de negocio, desarrollo y testing.
- Herramientas comunes: Cucumber, SpecFlow, Behave.
Preguntas típicas de examen (con respuesta breve)
-
¿Qué es BDD? Una práctica que describe el comportamiento empresarial en lenguaje natural y lo utiliza como pruebas.
-
¿Qué significa Given-When-Then? Describe la condición previa, la acción y el resultado esperado de un escenario.
-
Menciona una herramienta BDD. Cucumber, SpecFlow o Behave.
-
¿Cuál es la diferencia principal entre BDD y TDD? BDD describe el comportamiento desde la perspectiva empresarial, TDD se enfoca en unidades técnicas.
-
¿Cuál es una ventaja de BDD? El equipo de negocio y desarrollo comparten un entendimiento común de los requisitos.
Fuentes principales
- https://cucumber.io/docs/bdd/
- https://specflow.org/bdd/
- https://en.wikipedia.org/wiki/Behavior-driven_development
Preguntas frecuentes
¿Cuál es el propósito principal de BDD?
BDD fomenta un entendimiento compartido del comportamiento del sistema entre el equipo de negocio, desarrollo y testing mediante ejemplos ejecutables en lenguaje natural.
¿Qué significa Given en un escenario?
Given describe el estado inicial y las condiciones previas que deben cumplirse antes de la acción.
¿Se puede usar BDD sin TDD?
BDD y TDD se complementan. BDD se enfoca en ejemplos empresariales, TDD en desarrollo técnico. Ambos pueden usarse juntos.
¿Qué papel juegan los equipos de negocio en BDD?
Los equipos de negocio formulan y validan escenarios. Se encargan de que las pruebas reflejen el comportamiento empresarial real.
¿Qué es un archivo de feature?
Un archivo de feature contiene escenarios descritos en sintaxis Gherkin que documentan el comportamiento de una funcionalidad desde la perspectiva del usuario.
¿Qué es Gherkin?
Gherkin es un lenguaje simple y estructurado para escenarios BDD. Utiliza palabras clave como Feature, Scenario, Given, When, Then, And y But.
¿Qué son Step Definitions?
Step Definitions conectan los escenarios en lenguaje natural con el código ejecutable que realiza las acciones de prueba reales.
¿Es BDD solo para aplicaciones web?
No. BDD puede usarse para cualquier tipo de software, siempre que el comportamiento pueda describirse mediante ejemplos.
¿Qué es un anti-patrón BDD?
Los escenarios demasiado técnicos o detallados que se enfocan en la implementación en lugar del comportamiento empresarial son anti-patrones típicos.
¿Cómo difiere BDD de los documentos de requisitos clásicos?
Los escenarios BDD son ejecutables y se usan directamente como pruebas. Los documentos estáticos quedan obsoletos rápidamente, mientras que BDD sirve como documentación viva.
¿Qué es Specification by Example?
Specification by Example es un enfoque relacionado donde los requisitos se especifican mediante ejemplos concretos. BDD utiliza esta idea directamente para pruebas ejecutables.
¿Qué lenguajes de programación soporta Cucumber?
Cucumber soporta Java, JavaScript, Ruby, Python, C# y Kotlin, entre otros.
¿Cuántos escenarios debería contener un archivo de feature?
Un archivo de feature debe permanecer manejable. Varios escenarios relacionados por feature tienen sentido, pero si hay demasiados se recomienda dividirlos.
¿Qué es un reporte BDD?
Un reporte BDD muestra qué escenarios tuvieron éxito y cuáles fallaron. Sirve simultáneamente como evidencia de requisitos cumplidos.
¿Vale la pena usar BDD en equipos pequeños?
Sí, incluso equipos pequeños se benefician de requisitos más claros y documentación viva. Sin embargo, el esfuerzo debe ajustarse al proyecto.
Continúa en la ruta de aprendizaje de Software Testing
El siguiente artículo en la ruta de aprendizaje de Software Testing trata sobre Testautomatización y calidad de software, explicando cómo la automatización de pruebas mejora la calidad del software.