Desarrollo guiado por 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.[10][11] Cada historia de usuario, de alguna forma, debe seguir la siguiente estructura de seguimiento:[2][11]

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.[2][11] 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.[11] 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.[12]

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.[13][14][15]

El desarrollo guiado por el comportamiento toma prestado el concepto de lenguaje ubicuo del diseño guiado por el dominio.[2][4] 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.[16] 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.[16] 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.[2][6]

Un riesgo común con el desarrollo de software incluye fallos en la comunicación entre desarrolladores y partes interesadas en el negocio (inversores).[17] 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.[2] Asimismo, tener tal lenguaje crea un modelo de dominio de especificaciones, para que así las especificaciones puedan ser reflexionadas formalmente.[18] 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.

En principio una herramienta de soporte DGC es un armazón para probar software, similar a las herramientas que asisten al DGP. Sin embargo, donde las herramientas DGP tienden a ser libres de formato referente a lo que se permite para pruebas de especificación, las herramientas DGC están relacionadas con la definición del lenguaje ubicuo discutida anteriormente.

Como se mencionó, el lenguaje ubicuo permite a los analistas de negocios el escribir requerimientos de comportamiento de tal forma que los desarrolladores lo puedan entender. El principio del utillaje de asistencia DGC es el convertir estos documentos de requerimientos directamente ejecutables en una colección de pruebas. La implementación exacta de esto varía por cada herramienta, pero la práctica ágil ha presentado el proceso general siguiente:

• El utillaje lee un documento en específico.
• El utillaje entiende directamente las partes completamente formales del lenguaje ubicuo (como la palabra clave Dado que). Basado en esto, la herramienta divide cada escenario en cláusulas relevantes.
• Cada cláusula individual en un escenario se transforma en un tipo de parámetro para la prueba de la historia de usuario. Esta parte requiere trabajo específico del proyecto por parte de los desarrolladores..
• El armazón después ejecuta la prueba para cada escenario, usando los parámetros que le pertenecen a ese escenario.

Dan North ha desarrollado un número de armazones que apoyan el uso del DGC (incluyendo JBehave y RBehave), cuya operación se basa en la plantilla que él sugirió para recopilar historias de usuarios.[2] Estas herramientas usan una descripción textual para casos de uso y varias otras herramientas (como CBehave). Sin embargo, este formato no es requerido y por lo tanto hay otras herramientas que usan otros formatos también. Por ejemplo Fitnesse (que se construyó alrededor de tablas de decisión), también se ha usado para desplegar DGC.[19]

Existen varios ejemplos diferentes del utillaje de software de DGC para uso en proyectos hoy en día, para distintas plataformas y lenguajes de programación.

Posiblemente el más conocido es JBehave, que fue desarrollado por Dan North. El siguiente es un ejemplo tomado de ese proyecto:[14]

Considere una implementación del Juego de la vida. Un experto en dominios (o analista de negocios) tal vez quiera especificar lo que deba pasar cuando alguien prepara una configuración de inicio en la red del juego. Para lograr esto, él tal vez quiera dar un ejemplo del número de pasos dados por una persona que está cambiando de celdas. Saltándonos la parte narrativa, él tal vez haga esto al escribir el siguiente escenario en un documento de texto común y corriente (que es el tipo de documento de ingreso que JBehave lee):

Dado que se tiene un juego 5 por 5
Cuando yo alterne la celda en (3, 2)
Entonces la red debería verse así
.....
.....
.....
..X..
.....
Cuando yo alterne la celda en (3, 1)
Entonces la red debería verse así
.....
.....
.....
..X..
..X..
Cuando yo alterne la celda en (3, 2)
Entonces la red debería quedar así
.....
.....
.....
.....
..X..

Las palabras resaltadas no son parte de la entrada; se incluye aquí para mostrar cuáles palabras se distinguen como lenguaje formal. JBehave reconoce los términos Dado que (como precondición que define el inicio de un escenario). Cuando (como un detonador) y Entonces (como una pos-condición que debe ser verificada como el resultado de la acción que le sigue al detonador). Basado en esto, JBehave es capaz de leer el archivo de texto que contiene el escenario y de hacer un análisis sintáctico para convertirlo en cláusulas (una cláusula de preparación y después tres detonadores de eventos con condiciones verificables). JBehave después toma estas cláusulas y las pasa a código que es capaz de preparar una prueba, respondiendo a los detonadores de eventos y verificando el resultado. Este código debe estar escrito por los desarrolladores en el equipo del proyecto (en Java, porque esa es la plataforma en que se basa JBehave). En este caso, el código puede verse así:

private Game game;
private StringRenderer renderer;

@Given("a $width by $height game")
public void theGameIsRunning(int width, int height) {
    game = new Game(width, height);
    renderer = new StringRenderer();
    game.setObserver(renderer);
}
    
@When("I toggle the cell at ($column, $row)")
public void iToggleTheCellAt(int column, int row) {
    game.toggleCellAt(column, row);
}

@Then("the grid should look like $grid")
public void theGridShouldLookLike(String grid) {
    assertThat(renderer.asString(), equalTo(grid));
}

El código tiene un método para cada tipo de cláusula en un escenario. JBehave identificará cuál método va con cuál cláusula a través del uso de anotaciones y podrá llamar a cada método en orden mientras corre el escenario. El texto en cada cláusula en el escenario tiene que ser el mismo al de la plantilla de texto dada en el código para esa cláusula (por ejemplo, a Dado que en un escenario debe seguir una cláusula de la forma "juego X por Y"). JBehave espera la coincidencia de cláusulas con plantillas y tiene integrado el apoyo para escoger términos de la plantilla y pasarlos a los métodos en el código de prueba como parámetros. El código de prueba provee la implementación para cada tipo de cláusula en un escenario, la cual interactúa con el código que está siendo probado y lleva a cabo una prueba basada en el escenario. En este caso:

• El método "juego está corriendo" theGameIsRunning reacciona a la cláusula Dado que al preparar el juego de red inicial.
• El método "alterno la celda en" iToggleTheCellAt reacciona a la cláusula Cuando al disparar el evento de alternar que está descrito en la cláusula.
• El método "la red debería verse así" theGridShouldLookLike reacciona a la cláusula Entonces al comparar el estado actual de la red del juego al estado esperado del escenario.

La función primaria de este código es el ser un puente entre un archivo de texto con una historia y el código en sí que se está probando. Cabe recalcar que el código de prueba tiene acceso al código que está siendo probado (en este caso una instancia del Juego) y es muy simple en su naturaleza. El código de prueba tiene que ser simple, ya que de otra forma un desarrollador terminaría escribiendo pruebas para sus pruebas.

Finalmente, para logar correr las pruebas, JBehave requiere de un poco de "código de plomería" que identificará los archivos de texto que contienen escenarios y que agregan dependencias (como instancias de Juego) dentro del código de prueba. Este código de plomería no está ilustrado aquí, ya que es un requerimiento técnico de JBehave y no se relaciona directamente al estilo principal del estilo de prueba DGC.