miniaturadeimagen|Desarrollador programando En la Ingeniería de Software, behavior-driven development (BDD) o desarrollo guiado por el comportamiento (DGC) es un proceso de desarrollo de software que surgió a partir del desarrollo guiado por pruebas (DGP o TDD). El desarrollo guiado por el comportamiento combina las técnicas generales y los principios del DGP, junto con ideas del diseño guiado por el dominio y el análisis y diseño orientado a objetos para proveer al desarrollo de software y a los equipos de administración de herramientas compartidas y un proceso compartido de colaboración en el desarrollo de software.
Aunque el DGC es esencialmente una idea sobre cómo el desarrollo de software debería ser administrado tanto por los intereses del negocio como por el entendimiento técnico, la práctica del DGC asume el uso de herramientas de software especializadas para asistir en el proceso de desarrollo. Aunque estas herramientas son comúnmente desarrolladas específicamente para su uso en proyectos de DGC, se pueden ver como formas especializadas de las herramientas que asisten en el DGP. Las herramientas sirven para agregar automatización para el lenguaje ubicuo (lenguaje estructurado alrededor del modelo de dominio, utilizado en el diseño guiado por el dominio para conectar actividades entre miembros del equipo), el cual es el tema central del DGC.
Historia El desarrollo guiado por el comportamiento fue desarrollado por Dan North como respuesta a los problemas que surgían al enseñar el desarrollo guiado por pruebas:
Dónde comenzar en el proceso Qué probar y qué no probar Qué tanto abarca una prueba Cómo llamar a las pruebas Cómo entender por qué falla una prueba
En el corazón del DGC existe una reconsideración de la aproximación a la prueba unitaria y a la prueba de validación que North sugirió mientras lidiaba con estos problemas. Por ejemplo, él propone que los nombres de las pruebas unitarias sean oraciones completas empezando con la palabra "deber"/"debería" y que deberían estar escritas en el orden de importancia de rentabilidad en el negocio. Las pruebas de validación deberían estar escritas usando el armazón estándar ágil de una historia de usuario: "Como un [rol] yo deseo [características] para que así exista [beneficio]". Los criterios de validación deberían estar escritos en términos de las situaciones y además implementados como cláusulas: (usando el principio Given-When-Then) Dado que [contexto inicial], cuando [ocurre el evento], entonces [asegurar algunos resultados].
A partir de este punto, North y otros desarrollaron el armazón del DGC en el transcurso de algunos años, finalmente enmarcándolo como un armazón de comunicación y colaboración para desarrolladores, para el aseguramiento de la calidad y para participantes no técnicos o enfocados en los negocios en un proyecto de software.D.North, comments, The RSpec Book – Question about Chapter 11: Writing software that matters Durante el congreso "Especificaciones ágiles, DGC y Pruebas" ("Agile specifications, BDD and Testing eXchange") en noviembre de 2009 en Londres, Dan NorthDan North: How to sell BDD to the business dio la siguiente descripción del DGC: El DGC es una metodología ágil de segunda generación, tipo afuera hacia adentro, basada en jalar, siendo vehículo de múltiples partes interesadas, de escala múltiple, y de alta automatización. Describe un ciclo de interacciones con producciones bien definidas, resultando en el envío de software funcional, probado y trascendente.
Dan North creó el primer armazón del DGC, JBehave, seguido por un armazón nivel de historia DGC para Ruby llamado RBehave,D.North, Introducing RBehave el cual fue integrado más tarde al proyecto RSpec.S.Miller, InfoQ: RSpec incorporates RBehave North también colaboró con David Chelimsky, Aslak Hellesøy entre otros, para desarrollar RSpec y también para escribir el libro "The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends". El primer armazón basado en historia dentro de RSpec fue reemplazado poco tiempo después por Cucumber, principalmente desarrollado por Aslak Hellesøy.
En el 2008, Chris Matts, quien estuvo involucrado en las primeras discusiones alrededor del DGC, ideó el Feature Injection (inserción de característica), logrando así que el DGC pudiera cubrir el espacio de análisis y proveer un tratamiento completo al ciclo de vida del software, desde la visión hasta el código y el lanzamiento.
Principios del DGC En sí, el desarrollo guiado por el comportamiento es una forma especializada de la lógica de Hoare aplicada al desarrollo guiado por pruebas, y que finalmente se enfoca en especificaciones conductistas acerca de las unidades de software que usan el lenguaje del dominio de la situación.
El desarrollo guiado por pruebas (TDD) es una metodología de desarrollo de software que esencialmente afirma que por cada unidad de software, un desarrollador de software debe:
primero definir un conjunto de pruebas para la unidad; después implementar la unidad; finalmente verificar que la implementación de la unidad haga exitosas las pruebas.
Esta definición es poco específica, referente a que permite pruebas en términos de requerimientos de software de alto nivel, detalles técnicos de bajo nivel o cualquier cosa entre éstos límites. El desarrollador original del DGC (Dan North) propuso la noción del DGC debido a que no estaba satisfecho con la falta de especificaciones dentro del DGP, referente a lo que debe ser probado y cómo. Una forma de ver al DGC entonces, es que es un desarrollo continuo del DGP, por lo que toma decisiones más específicas que el DGP.
El desarrollo guiado por el comportamiento señala que las pruebas de cualquier unidad de software deben ser especificadas en términos del comportamiento deseado de la unidad. Tomando prestado del desarrollo ágil de software, el concepto de "comportamiento deseado" en este caso consiste en los requerimientos definidos por el negocio -- esto es, el comportamiento deseado que tiene valor rentable para cualquier entidad que haya comisionado la unidad de software que se encuentra en construcción. Dentro de la práctica del DGC, esto es lo que apunta a que el DGC es una actividad "afuera-hacia-adentro".
Especificaciones del comportamiento Siguiendo esta decisión fundamental, una segunda decisión hecha por el DGC se relaciona con el cómo debe ser especificado el comportamiento deseado. En esta área el DGC escoge usar un formato no completamente formal para especificar el comportamiento. Esto se toma prestado de las especificaciones de la historia de usuario, específicamente del campo de análisis y diseño orientado a objetos. El DGC especifica que los analistas de negocios y los desarrolladores deben colaborar en esta área y además deben señalar el comportamiento en términos de las historias de usuario, las cuales son escritas explícitamente en un documento dedicado. Cada historia de usuario, de alguna forma, debe seguir la siguiente estructura de seguimiento:
Título: La historia debe tener un título claro y explícito. Narrativa Una pequeña sección de introducción que especifique quién (cuál negocio o rol del proyecto) es el conductor o principal parte interesada de la historia (el actor que recibe beneficios de la historia) qué efecto se quiere en la historia, señalado por la parte interesada qué remuneración tendrá la parte interesada a partir de este efecto Criterios de aceptación o escenarios Es una descripción de cada caso específico de la narrativa. Tal escenario tiene la siguiente estructura: Comienza al especificar la condición inicial, la cual es asumida como verdadera al inicio del escenario. Esto puede consistir en una causa o varias. Después declara cuál evento causa el inicio del escenario. Finalmente, declara el resultado esperado, en una o más cláusulas.
El DGC no tiene requerimientos formales para describir exactamente cómo estas historias de usuario deben ser escritas, pero sí insiste en que cada equipo utilizando el DGC declare un formato simple y estandarizado para escribir las historias de usuario, el cual incluye los elementos listados arriba. Sin embargo, en 2007 Dan North sugirió una plantilla para un formato textual, la cual ha encontrado amplio seguimiento en diferentes herramientas DGC de software. Un pequeño ejemplo de este formato puede verse así: Historia: Devoluciones van al inventario
A fin de tener seguimiento del inventario Siendo un dueño de tienda Yo quiero añadir artículos de regreso al inventario cuando sean devueltos
Escenario 1: Artículos reembolsados deben ser regresados al inventario Dado que un cliente previamente me compró un suéter negro Y actualmente me quedan tres suéteres negros en el inventario Cuando él devuelva el suéter a cambio de un reembolso Entonces yo debo tener cuatro suéteres en el inventario
Escenario 2: Artículos reemplazados deben ser regresados al inventario Dado que un cliente compra una prenda azul Y yo tengo dos prendas azules en el inventario Y tres prendas negras en el inventario Cuando él regresa la prenda para un reemplazo por una negra, Entonces yo debo tener tres prendas azules en el inventario Y dos negras en el inventario
Los escenarios están idealmente expresados de una forma declarativa en lugar de imperativa -- en el lenguaje del negocio, sin referencia a los elementos de la UI, a través de la cual las interacciones ocurren.
Este formato es conocido como el lenguaje Gherkin, que tiene una sintaxis similar al ejemplo de arriba. El término Gherkin, sin embargo, es único para las herramientas de software Cucumber, JBehave y Behat.
La especificación como lenguaje ubicuo El desarrollo guiado por el comportamiento toma prestado el concepto de lenguaje ubicuo del diseño guiado por el dominio. Un lenguaje ubicuo es un lenguaje semiformal compartido por todos los miembros de un equipo de desarrollo de software -- tanto desarrolladores de software como personal no técnico. El lenguaje en cuestión es usado y desarrollado por todos los miembros del equipo para ser un medio común para la discusión del dominio del software en cuestión. De esta forma el DGC se convierte en un vehículo para la comunicación entre todos los roles diferentes en un proyecto de software.
Un riesgo común con el desarrollo de software incluye fallos en la comunicación entre desarrolladores y partes interesadas en el negocio (inversores). El DGC usa la especificación del comportamiento deseado como un lenguaje ubicuo para los miembros del equipo del proyecto. Esta es la razón de que el DGC insiste en usar un lenguaje semiformal para la especificación del comportamiento: sólo un poco de formalidad es un requerimiento para ser un lenguaje ubicuo. Asimismo, tener tal lenguaje crea un modelo de dominio de especificaciones, para que así las especificaciones puedan ser reflexionadas formalmente. Este modelo es también base para las diferentes herramientas de software disponibles que usan DGC.
El ejemplo dado arriba establece una historia de usuario para un sistema de software en desarrollo. Esta historia identifica a la parte interesada, un efecto de negocio y valor de negocio. Asimismo describe varios escenarios, cada uno con una precondición, un detonador y un resultado esperado. Cada una de estas partes está definida exactamente por la parte más formal del lenguaje (el término Dado que puede considerarse como una palabra clave, por ejemplo) y por tal causa es posible que sea procesada de alguna manera por una herramienta que entienda las partes formales del lenguaje ubicuo.
Utillaje de asistencia especializada Muy parecido a lo que es la práctica del diseño guiado por pruebas, el DGC asume el uso de utillaje de asistencia especializada en un proyecto. Por más que el DGC sea, en muchos aspectos, una versión más específica del DGP, el utillaje para DGC es similar al de DGP, pero le hace más demandas al desarrollador que el utillaje básico de DGP.