Diferencia entre revisiones de «Behavior Driven Development»
| Línea 18: | Línea 18: | ||
# '''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. | # '''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. | #'''Demostración'''. Una vez que todos los tests pasan la historia puede ser demostrada al dueño de producto. | ||
| + | |||
| + | ==Herramientas y frameworks de BDD== | ||
| + | * [[Concordion]] | ||
| + | * [[JBehave]] | ||
| + | |||
| + | ==Ver también== | ||
| + | * [[Testing De Aplicaciones]] | ||
| + | * [[Metodologias De Desarrollo]] | ||
| + | * [[Test Driven Development]] | ||
| + | * [http://en.wikipedia.org/wiki/Behavior_Driven_Development TDD en la Wikipedia] | ||
| + | * [http://behaviour-driven.org/] | ||
| + | * [http://dannorth.net/introducing-bdd] | ||
| + | * [[http://www.dosideas.com/metodologias/484-calidad-de-software-con-bdd-y-atdd.html Calidad de software con BDD y ATDD]] | ||
Revisión del 19:31 25 jun 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.
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.
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 éstos 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.
