Diferencia entre revisiones de «Behavior Driven Development»
(→Ver también) |
|||
| (No se muestran 3 ediciones intermedias de 2 usuarios) | |||
| Línea 3: | Línea 3: | ||
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. | 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. | 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. | ||
== Prácticas de BDD == | == Prácticas de BDD == | ||
| Línea 10: | 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 == | ||
| Línea 27: | Línea 31: | ||
* [[Desarrollo Agil De Software]] | * [[Desarrollo Agil De Software]] | ||
* [[Test Driven Development]] | * [[Test Driven Development]] | ||
| + | * [[Acceptance Test Driven Development]] | ||
* [http://en.wikipedia.org/wiki/Behavior_Driven_Development TDD en la Wikipedia] | * [http://en.wikipedia.org/wiki/Behavior_Driven_Development TDD en la Wikipedia] | ||
* [http://behaviour-driven.org/ Sitio oficial de Behaviour Driven Development] | * [http://behaviour-driven.org/ Sitio oficial de Behaviour Driven Development] | ||
* [http://dannorth.net/introducing-bdd Introducción a BDD por Dan North] | * [http://dannorth.net/introducing-bdd Introducción a BDD por Dan North] | ||
* [http://www.dosideas.com/metodologias/484-calidad-de-software-con-bdd-y-atdd.html Calidad de software con BDD y ATDD] | * [http://www.dosideas.com/metodologias/484-calidad-de-software-con-bdd-y-atdd.html Calidad de software con BDD y ATDD] | ||
| + | |||
| + | [[Category:BDD]] | ||
Revisión actual del 14:28 31 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.
