Behavior Driven Development (BDD)

El Desarrollo Basado en el Comportamiento (BDD, por sus siglas en inglés) es una síntesis y refinamiento de las prácticas derivadas del Desarrollo Basado en Pruebas (TDD, por sus siglas en inglés) y el Desarrollo Basado en Pruebas de Aceptación (ATDD, por sus siglas en inglés). BDD aumenta TDD y ATDD con las siguientes tácticas:

  • Aplicar el principio de los “cinco por qué” a cada historia de usuario propuesta, de modo que su propósito esté claramente relacionado con los resultados del negocio.
  • Pensar “de afuera hacia adentro”, es decir, implementar sólo aquellos comportamientos que contribuyen más directamente a estos resultados de negocio, con el fin de minimizar el desperdicio.
  • Describir comportamientos en una sola notación que sea directamente accesible a los expertos del dominio, probadores y desarrolladores, con el fin de mejorar la comunicación.
  • Aplicar estas técnicas hasta los niveles más bajos de abstracción del software, prestando especial atención a la distribución del comportamiento, para que la evolución siga siendo barata.

También conocido como

El BDD también se denomina Especificación por ejemplo.

Beneficios Esperados

Los equipos que ya están usando TDD o ATDD pueden querer considerar BDD por varias razones:

  • BDD ofrece una guía más precisa sobre la organización de la conversación entre desarrolladores, probadores y expertos en dominios.
  • Las notaciones que se originan en el enfoque BDD, en particular el lienzo dado-cuando-entonces, están más cerca del lenguaje cotidiano y tienen una curva de aprendizaje menos profunda que las de herramientas como Fit/FitNesse.
  • Las herramientas que apuntan a un enfoque de BDD generalmente permiten la generación automática de documentación técnica y de usuario final a partir de las “especificaciones” de BDD.

Obstáculos comunes

Aunque Dan North, que fue quien formuló por primera vez el enfoque BDD, afirma que fue diseñado para abordar cuestiones recurrentes en la enseñanza de la TDD, está claro que la BDD requiere familiaridad con una mayor gama de conceptos que la TDD, y parece difícil recomendar que un programador principiante aprenda primero la BDD sin una exposición previa a los conceptos de la TDD.

El uso de BDD no requiere herramientas o lenguajes de programación particulares, y es principalmente un enfoque conceptual; convertirlo en una práctica puramente técnica o en una práctica que depende de herramientas específicas sería perder el punto en su totalidad.

Orígenes

2003: agiledox, antepasado de BDD, es una herramienta que genera documentación técnica automáticamente a partir de JUnit tests, escrita por Chris Stevenson
2004: con el fin de poner a prueba sus hipótesis sobre la reducción de la importancia de la terminología “test” en favor de la “conducta”, Dan North publica JBehave
2006: en colaboración con Chris Matts, North propone el lienzo dado-cuando-entonces para expandir el alcance de BDD al análisis de negocios y documenta el enfoque en “Introduciendo BDD”.
2006-2009: se lanzan varias herramientas nuevas que confirman la inversión de la comunidad en BDD, como RSpec o, más recientemente, Cucumber y GivWenZen.

Señales de uso

  • Un equipo que utilice BDD debería ser capaz de proporcionar una parte significativa de la “documentación funcional” en forma de Historias de Usuario aumentadas con escenarios ejecutables o ejemplos.
  • En lugar de referirse a “pruebas”, un practicante de BDD preferirá los términos “escenario” y “especificación”. Tal como se practica actualmente, el BDD pretende reunir en un solo lugar la especificación de un resultado valioso para un usuario, generalmente utilizando la matriz de funciones de roles de (Historias de usuarios), así como ejemplos o escenarios expresados en la forma en que se dan-cuando-entonces; estas dos notaciones a menudo se consideran las más legibles.
  • Al enfatizar el término “especificación”, la intención de BDD es proporcionar una respuesta única a lo que muchos equipos ágiles ven como actividades separadas: la creación de pruebas unitarias y código “técnico”, por un lado, y la creación de pruebas funcionales y “características”, por otro. Esto debería conducir a una mayor colaboración entre los desarrolladores, los especialistas en pruebas y los expertos en la materia.
  • En lugar de referirse a “las pruebas unitarias de una clase”, un practicante o un equipo que utiliza BDD prefiere hablar de “las especificaciones del comportamiento de la clase”. Esto refleja una mayor atención a la función documental de dichas especificaciones: se espera que sus nombres sean más expresivos y, cuando se completen con su descripción en un formato determinado, sirvan como documentación técnica.
  • En lugar de referirse a “pruebas funcionales”, el término preferido será “especificaciones del comportamiento del producto”. Los aspectos técnicos de los BDD se sitúan en pie de igualdad con las técnicas que fomentan una conversación más eficaz con los clientes, usuarios y expertos en la materia.
  • Además de las técnicas de refactorización ya presentes en la DDT, la filosofía de diseño de la BDD presta especial atención a la adecuada distribución de responsabilidades entre las clases, lo que lleva a sus practicantes a hacer hincapié en la “burla”.

 

Lecturas Recomendadas

 

Deja un comentario

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar