Behavior-Driven Development: Difference between revisions
Created page with "{{Meta-bok|min=4}} El '''Behavior-Driven Development''' (BDD, desarrollo guiado por comportamiento) es una extensión de Test-Driven Development que traslada el foco de las pruebas técnicas al comportamiento esperado del sistema desde la perspectiva del usuario de negocio. Las pruebas se escriben en lenguaje natural estructurado —comprensible para personas no técnicas— antes de que el código exista, siguiendo el formato '''Given/When/Then''' (dado/cuando/e..." |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
'''Ejemplo:''' | '''Ejemplo:''' | ||
<blockquote><small> | |||
'''Given''' que el usuario ha iniciado sesión y tiene saldo suficiente,<br> | '''Given''' que el usuario ha iniciado sesión y tiene saldo suficiente,<br> | ||
'''When''' transfiere 100€ a otra cuenta,<br> | '''When''' transfiere 100€ a otra cuenta,<br> | ||
'''Then''' su saldo se reduce en 100€ y la transacción aparece en el historial. | '''Then''' su saldo se reduce en 100€ y la transacción aparece en el historial.</small></blockquote> | ||
Este escenario puede ser escrito por el propietario del producto o el analista de negocio, revisado por el equipo técnico y ejecutado automáticamente por una herramienta de BDD como Cucumber o Behave. | Este escenario puede ser escrito por el propietario del producto o el analista de negocio, revisado por el equipo técnico y ejecutado automáticamente por una herramienta de BDD como Cucumber o Behave. | ||
| Line 26: | Line 25: | ||
* '''Documentación viva:''' los escenarios son a la vez especificación y prueba: cuando el código cambia, las pruebas detectan si el comportamiento esperado también ha cambiado. | * '''Documentación viva:''' los escenarios son a la vez especificación y prueba: cuando el código cambia, las pruebas detectan si el comportamiento esperado también ha cambiado. | ||
* '''Cobertura orientada al valor:''' las pruebas BDD se centran en lo que importa al usuario, no en los detalles de implementación técnica. | * '''Cobertura orientada al valor:''' las pruebas BDD se centran en lo que importa al usuario, no en los detalles de implementación técnica. | ||
* '''Facilita el [[Spec-Driven Development|SDD]]:''' los escenarios Given/When/Then son una forma de spec legible tanto por personas como por agentes de IA. | * '''Facilita el [[Spec-Driven Development (SDD)|SDD]]:''' los escenarios Given/When/Then son una forma de spec legible tanto por personas como por agentes de IA. | ||
== BDD y la IA == | == BDD y la IA == | ||
| Line 41: | Line 40: | ||
'''Usar BDD solo como herramienta técnica de testing, ignorando el lenguaje compartido.''' El valor de BDD no está en Cucumber o Gherkin: está en que las personas de negocio y las técnicas colaboran para definir el comportamiento antes de construirlo. Si los escenarios Given/When/Then los escribe solo el equipo técnico sin participación del propietario del producto o los usuarios, BDD se convierte en TDD con sintaxis diferente. | '''Usar BDD solo como herramienta técnica de testing, ignorando el lenguaje compartido.''' El valor de BDD no está en Cucumber o Gherkin: está en que las personas de negocio y las técnicas colaboran para definir el comportamiento antes de construirlo. Si los escenarios Given/When/Then los escribe solo el equipo técnico sin participación del propietario del producto o los usuarios, BDD se convierte en TDD con sintaxis diferente. | ||
</div> | </div> | ||
== Recursos == | |||
<div class="bok-recurso"> | |||
📄 [https://scrummanager.com/files/scrumenequiposconia.pdf '''Scrum Master en equipos con IA v.1.0''']<span class="detalle">Descarga gratuita · Scrum Manager</span> | |||
</div> | |||
== Referencias == | == Referencias == | ||
| Line 49: | Line 51: | ||
<div class="bok-tags"> | <div class="bok-tags"> | ||
[[TDD]] [[Criterios de aceptación]] [[Definición de hecho]] [[Spec-Driven Development]] [[Agilidad técnica]] [[Historia de usuario]] [[Extreme programming]] | [[TDD]] [[Criterios de aceptación]] [[Definición de hecho]] [[Spec-Driven Development (SDD)]] [[Agilidad técnica]] [[Historia de usuario]] [[Extreme programming]] | ||
</div> | </div> | ||
Latest revision as of 11:42, 25 May 2026
El Behavior-Driven Development (BDD, desarrollo guiado por comportamiento) es una extensión de Test-Driven Development que traslada el foco de las pruebas técnicas al comportamiento esperado del sistema desde la perspectiva del usuario de negocio. Las pruebas se escriben en lenguaje natural estructurado —comprensible para personas no técnicas— antes de que el código exista, siguiendo el formato Given/When/Then (dado/cuando/entonces).
Dan North acuñó el término en 2003 como evolución de TDD, observando que el principal problema de TDD no era técnico sino de comunicación: los desarrolladores no sabían qué cosas probar, y los tests técnicos no eran legibles para los stakeholders de negocio.
El formato Given/When/Then
BDD estructura cada escenario de comportamiento en tres cláusulas:
- Given (dado): el estado inicial del sistema o el contexto en el que ocurre la acción.
- When (cuando): la acción que realiza el usuario o el sistema.
- Then (entonces): el resultado esperado que puede verificarse.
Ejemplo:
Given que el usuario ha iniciado sesión y tiene saldo suficiente,
When transfiere 100€ a otra cuenta,
Then su saldo se reduce en 100€ y la transacción aparece en el historial.
Este escenario puede ser escrito por el propietario del producto o el analista de negocio, revisado por el equipo técnico y ejecutado automáticamente por una herramienta de BDD como Cucumber o Behave.
Beneficios
- Lenguaje compartido: los escenarios BDD son comprensibles tanto para stakeholders de negocio como para desarrolladores, reduciendo malentendidos en los criterios de aceptación.
- Documentación viva: los escenarios son a la vez especificación y prueba: cuando el código cambia, las pruebas detectan si el comportamiento esperado también ha cambiado.
- Cobertura orientada al valor: las pruebas BDD se centran en lo que importa al usuario, no en los detalles de implementación técnica.
- Facilita el SDD: los escenarios Given/When/Then son una forma de spec legible tanto por personas como por agentes de IA.
BDD y la IA
BDD tiene una sinergia directa con el desarrollo asistido por IA:
- Los escenarios Given/When/Then pueden usarse como especificación para que un agente de IA genere el código que los satisface: la prueba precede al código, tal como prescribe TDD.
- Los escenarios escritos por el equipo en lenguaje natural son más resistentes a las alucinaciones que las specs puramente técnicas, porque están anclados en comportamientos de usuario verificables.
- Las herramientas de IA pueden ayudar a transformar historias de usuario en escenarios BDD, aunque la revisión humana de la cobertura de casos extremos sigue siendo imprescindible.
Error frecuente
Usar BDD solo como herramienta técnica de testing, ignorando el lenguaje compartido. El valor de BDD no está en Cucumber o Gherkin: está en que las personas de negocio y las técnicas colaboran para definir el comportamiento antes de construirlo. Si los escenarios Given/When/Then los escribe solo el equipo técnico sin participación del propietario del producto o los usuarios, BDD se convierte en TDD con sintaxis diferente.
Recursos
📄 Scrum Master en equipos con IA v.1.0Descarga gratuita · Scrum Manager
Referencias
- North, Dan. (2006). "Introducing BDD". dannorth.net.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.