BDD (abreviado del inglés Behavior-driven development , literalmente " desarrollo a través del comportamiento ") es una metodología de desarrollo de software que es una rama de la metodología de desarrollo basado en pruebas (TDD).
La idea principal de esta metodología es la combinación de intereses puramente técnicos e intereses comerciales en el proceso de desarrollo, lo que permite que el personal de administración y los programadores hablen el mismo idioma. Para la comunicación entre estos grupos de personal, se utiliza un lenguaje específico de dominio , que se basa en construcciones de lenguaje natural que son comprensibles para un no especialista, generalmente expresando el comportamiento de un producto de software y los resultados esperados.
Se cree que este enfoque es efectivo cuando el área temática en la que opera el producto de software se describe de una manera muy compleja.
La metodología BDD es una extensión de TDD en el sentido de que antes de escribir cualquier prueba, primero debe describir el resultado deseado de la funcionalidad agregada en un lenguaje específico del dominio. Una vez hecho esto, las construcciones de este lenguaje son traducidas por especialistas o software especial en una descripción de prueba.
BDD se centra en las siguientes preguntas:
Con base en estas preguntas, BDD requiere que los nombres de prueba sean oraciones completas que comiencen con un verbo en subjuntivo y sigan los objetivos comerciales. Las descripciones de las pruebas de aceptación deben escribirse en un lenguaje de historia de usuario flexible, p.
Como [papel de alguien cuyos intereses comerciales se sirven] quiero [describir la funcionalidad de la forma en que debería funcionar] para [describir el beneficio].
Los criterios de aceptación deben describirse en términos de un escenario que el usuario implementa para lograr el resultado.
Como ya se señaló, las pruebas para una pieza de software deben describirse en términos del comportamiento deseado del dispositivo programable. El comportamiento deseado aquí se refiere a uno que es de valor para el negocio. La descripción del comportamiento deseado se da con la ayuda de una especificación de comportamiento .
La especificación de comportamiento se construye de forma semiformal. Actualmente, se ha establecido la siguiente estructura en la práctica de BDD:
BDD no proporciona ninguna regla formal, pero insiste en que se use un conjunto estándar limitado de frases que incluiría todos los elementos de una especificación de comportamiento. En 2007, Dan North propuso una plantilla de especificación que ganó popularidad y se conoció como el lenguaje Gherkin [1] [2] .
Las frases básicas del idioma Gherkin se presentan en la siguiente tabla.
| palabra clave en ingles | adaptación al idioma ruso | Descripción |
|---|---|---|
| Historia ( Característica [3] ) |
Historia | Cada nueva especificación comienza con esta palabra clave seguida de dos puntos en la forma subjuntiva del nombre de la historia. |
| Como un | Cómo (en un papel) | El rol de la persona en el modelo de negocio que está interesada en esta funcionalidad. |
| Con el fin de | Para alcanzar | Brevemente, cuáles son los objetivos de la persona. |
| Yo quiero | Yo quiero | Describe brevemente el resultado final. |
| Guión | Guión | Cada escenario de una historia comienza con esta palabra, después de lo cual el objetivo del escenario se escribe en forma de subjuntivo, separado por dos puntos. Si hay varios escenarios en una historia, luego de la palabra clave se debe escribir su número ordinal. |
| Dado | Dado | Condición inicial. Si hay varias condiciones iniciales, cada nueva condición se agrega desde una nueva línea usando la palabra clave Y. |
| Cuando | Cuando ( nota : algo sucede) | El evento que desencadena este script. Si el evento no se puede revelar en una oración, todos los detalles subsiguientes se revelan a través de las palabras clave Y y Pero. |
| Después | Después | El resultado que el usuario eventualmente debería observar. Si el resultado no se puede revelar en una oración, todos los detalles subsiguientes se revelan a través de las palabras clave Y y Pero. |
| Y | Y | Palabra clave auxiliar, análogo de conjunción . |
| Pero | Pero | Palabra clave auxiliar, análogo de la negación . |
El siguiente ejemplo demuestra una especificación de comportamiento usando el lenguaje Gherkin.
| Historia: Las devoluciones van a stock Como propietario de una tienda Para realizar un seguimiento de las existencias , quiero volver a agregar artículos a las existencias cuando se devuelvan. Escenario 1 : los artículos reembolsados deben devolverse al inventario dado que un cliente me compró previamente un suéter negro y tengo tres suéteres negros en stock. Cuando devuelvan el suéter negro para un reembolso Entonces debería tener cuatro suéteres negros en stock. Escenario 2 : los artículos reemplazados deben devolverse al stock dado que un cliente me compró previamente una prenda azul y tengo dos prendas azules en stock y tres prendas negras en stock. Cuando devuelvan la prenda azul por una negra , entonces debería tener tres prendas azules en stock y dos prendas negras en stock. | Historial: El artículo devuelto debe mantenerse en stock Como propietario de una tienda Para realizar un seguimiento del inventario en el almacén , quiero restaurar los registros de los artículos que se devuelven al almacén. Escenario 1 : Los artículos devueltos deben colocarse en stock dado que un cliente me compró previamente un suéter negro Y ya tengo tres idénticos en stock. Cuando el cliente devuelve el suéter comprado , debería ver que ahora hay 4 suéteres negros en stock. Escenario 2 : Los artículos reemplazados deben devolverse al almacén dado que un cliente me compró una prenda azul Y tengo dos de estos artículos en azul Y tres artículos negros en mi almacén. Cuando un cliente devuelve una prenda azul para ser reemplazada por una similar pero negra Entonces debería ver que ahora hay tres artículos en stock para la prenda azul Y dos artículos para la prenda negra. |
El formato de especificación de comportamiento semiformal requiere el uso de un conjunto limitado de propuestas que el personal de administración y los desarrolladores deben acordar de antemano. En base a esto, los marcos para soportar BDD se construyen de acuerdo con los siguientes principios:
Los marcos como JBehave y RBehave, que se basan en el lenguaje Gherkin, se basan en este principio. Algunos marcos se construyen de manera similar, como CBehave y Cucumber.
Supongamos que estamos desarrollando un motor para el juego "Life" y necesitamos agregar la capacidad de colocar inicialmente células vivas en el campo. Supongamos que cuando el usuario selecciona algún punto libre del campo, aparece una celda viva sobre él. Si el usuario selecciona un punto de campo ya ocupado por una celda, la celda desaparece y el punto de campo queda libre. Las coordenadas del campo se ingresan en el formato (x,y), donde x es el número de punto horizontal e y es el número de punto vertical. El punto de referencia para ambas coordenadas comienza en la esquina superior izquierda, desde uno.
Omitiendo la descripción de la especificación de comportamiento por simplicidad, podemos escribir un script de este tipo en Gherkin.
Dado un juego de 5 por 5 Cuando alterno la celda en ( 3 , 4 ) Entonces la cuadrícula debería verse como ..... ..... ..... ..X .. ..... Cuando alternar la celda en ( 3 , 5 ) Entonces la cuadrícula debería verse como ..... ..... ..... ..X.. ..X.. Cuando alterne la celda en ( 3 , 4 ) Entonces la cuadrícula debería verse como ..... ..... ..... ..... ..X..El marco JBehave está escrito en Java, por lo que las pruebas se traducen a código Java. Para el marco JBehave, este script se pasa como un archivo de texto sin formato, que se lee línea por línea. Todo lo que necesita un desarrollador es proporcionar funciones que JBehave debería llamar cuando salta a la siguiente línea. Por ejemplo, una implementación de prueba podría verse así:
juego de juego privado ; StringRenderer privado ; _ @Given ( "un juego de $ancho por $alto" ) public void theGameIsRunning ( int ancho , int alto ) { juego = nuevo Juego ( ancho , alto ); renderizador = new StringRenderer (); juego _ setObserver ( procesador ); } @When ( "Alterno la celda en ($columna, $fila)" ) public void iToggleTheCellAt ( int columna , int fila ) { juego . toggleCellAt ( columna , fila ); } @Then ( "la cuadrícula debería parecerse a $grid" ) public void theGridShouldLookLike ( String grid ) { assertThat ( renderer . asString (), equalTo ( grid )); }Para asignar sin ambigüedades una función a una propuesta de Gherkin, se utilizan anotaciones de Java, que son proporcionadas por el marco JBehave. Por ejemplo, cuando el analizador del motor llega a cualquiera de las oraciones como
Cuando alterno la celda en (n, n)el motor JBehave calculará a partir de la anotación que se debe llamar al método
void iToggleTheCellAt ( columna int , fila int )además, la anotación está escrita de tal manera que el motor "entiende" que algunas partes de la oración deben capturarse y pasarse a la función como entrada (en este ejemplo, estas son las coordenadas del punto de campo). A continuación, la función llama a las funciones del propio juego "Life", y el desarrollador comprueba el comportamiento del motor del juego utilizando las herramientas habituales de TDD.
C/C++
|
Java
|