Diferencia entre revisiones de «Behavior Driven Development»
(→Prácticas de BDD) |
|||
| Línea 14: | Línea 14: | ||
* Involucrar a los interesados en el proceso | * Involucrar a los interesados en el proceso | ||
* Usar ejemplos para describir el comportamiento de la aplicación, o de unidades de código | * Usar ejemplos para describir el comportamiento de la aplicación, o de unidades de código | ||
| − | * Automatizar | + | * Automatizar estos ejemplos para proveer un rápido feedback y tests de regresión |
== Ciclo de desarollo BDD == | == Ciclo de desarollo BDD == | ||
Revisión del 23:59 24 ago 2009
Desarrollo guiado por comportamiento, o Behavior Driven Development (BDD) es una técnica de Desarrollo Agil De Software que fomenta la colaboración entre desarrolladores, testers, analistas y personas del negocio en un proyecto de software. Originalmente fué concebido por Dan North en 2003 como respuesta y evolución en el pensamiento detrás de Test Driven Development, uniendo éste con conceptos de Domain Driven Design.
El foco del BDD es el lenguaje e interacciones usadas en el proceso de desarrollo de software. Los desarrolladores guiados por comportamiento usan su lenguaje nativo en combinación con el lenguaje ubicuo de Domain Driven Design para describir el propósito y beneficios de su código. Esto permite a los desarrolladores enfocarse en por qué el código debe ser creado, antes que en los detalles técnicos, y minimiza la traducción entre el lenguaje técnico en el cuál se escribe el código y el lenguaje de dominio hablado por las personas del negocio, usuarios, interesados, gerentes de proyecto, etc.
BDD permite un entendimiento más global del sistema a crear, eliminando el efecto túnel de los desarrolladores que trabajan sólo con TDD. También crea un entendimiento común de todos los involucrados y ayuda a eliminar malos entendidos sobre lo que el sistema debe hacer.
De la misma forma que en TDD se escriben primero las pruebas unitarias, en BDD se escriben primero el comportamiento esperado de la aplicación, haciéndolo demostrable y automatizándolo en pruebas de aceptación, lo que se denomina especificación activa.
BDD y TDD no son excluyentes, sino que se pueden aplicar ambas prácticas, complementándose, comenzando el ciclo con las especificaciones con BDD y utilizando TDD en el ciclo de la codificación.
Contenido
Prácticas de BDD
- Involucrar a los interesados en el proceso
- Usar ejemplos para describir el comportamiento de la aplicación, o de unidades de código
- Automatizar estos ejemplos para proveer un rápido feedback y tests de regresión
Ciclo de desarollo BDD
- Discusión. Desarrolladores, testers, expertos de dominio y el dueño de producto se juntan y discuten la historia, gradualmente descomponiendo y destilando el comportamiento en un conjunto de especificaciones simples.
- Decisión. El dueño de producto decide cuando la especificación cumple suficientemente el comportamiento esperado y está de acuerdo con los casos de ejemplo y demostración de la historia y cierra el alcance de la misma.
- Desarrollo. Los testers refinan los ejemplos de la especificación y los desarrolladores instrumentan las especificaciones creando primero pruebas que fallan y después implementando la funcionalidad.
- Demostración. Una vez que todos los tests pasan la historia puede ser demostrada al dueño de producto.
