Behaviour Driven Development (BDD)

el




Behavior-Driven Development (BDD) o Desarrollo Guiado por el Comportamiento (DGC), es un proceso de desarrollo software, si bien se relaciona principalmente con el Testing, que es de donde surge.
El BDD combina las técnicas generales y los principios del desarrollo guidado por pruebas, 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, con herramientas compartidas y un proceso compartido de colaboración en el desarrollo de software.
            
BDD busca un lenguaje común para unir la parte técnica y la de negocio, y que sea desde ese lenguaje común desde donde arranque el Testing y, desde ahí, el desarrollo.
En BDD, las pruebas de aceptación se escriben usando historias de usuario, ya sabes aquello tan usado en agilidad …
El ciclo básico de BDD sería el siguiente…
  1. Escribir las historias de usuario.
  2. Escribir los escenarios.
  3. Automatizar las pruebas de aceptación.
              
En BDD, las pruebas de aceptación se escriben usando historias de usuario, con el siguiente formato:
 
 

Guerkin

El lenguaje Gherkin define la estructura y una sintaxis básica para la descripción de las pruebas que pueden ser entendidas tanto por los integrantes técnicos del equipo como así también por los Analistas/Programadores Orgánicos o quien quiera que este como representante del cliente. De esta manera mientras se generan pruebas se esta generando documentación viva que describe perfectamente como se comporta el sistema enriqueciendo y manteniendo la documentación.
El formato fue introducido por la herramienta Cucumber pero también es utilizado por otras herramientas derivadas de Cucumber como Specflow. 

Feature (Característica)

El elemento Feature proporciona el encabezado o el marco para el archivo Feature. Tiene un título y un texto con una descripción de alto nivel de la función de la aplicación que se detalla en el archivo. Contiene el listado de Scenarios que componen el feature, los cuales se pueden agrupar por tags.

Scenario (Escenario)

Un Scenario es una lista de pasos que comienza con algunas de estas palabras claves:

  • Given (|Dado|Dada|Dados|Dadas)
  • When (Cuando)
  • Then (Entonces)
  • But (Pero) o And (Y)
Ejemplo:

Característica: Servir café
El café no se debe servir hasta que se pague
El café no se debe servir hasta que se haya pulsado el botón
Si no queda café entonces el dinero debe ser devuelto
Escenario: Comprar último café
Dado que hay 1 café que quedan en la máquina
Y he depositado 1 $
Cuando presiono el botón de café
Entonces 1 café debería ser servido

Background (Antecedentes)

Utilizamos el Background para definir precondiciones para cada uno de los Scenarios a correr y así no ser repetitivos y focalizar los Scenarios en la prueba especifica.
Ejemplo:

Antecedentes:
Dado que estoy frente a la maquina de café
Y tengo 1$ para depositar
Escenario: Comprar último café
Dado que hay 1 café que quedan en la máquina
Y he depositado 1 $
Cuando presiono el botón de café
Entonces 1 café debería ser servido

Scenario Outline (Esquema del escenario)

Los Scenario Outline nos permiten introducir variables en nuestros Scenarios y así simplificar pruebas que requieren los mismos pasos pero que pueden tener datos variados. El Scenario Outline va junto a la tabla Examples (Ejemplos)  donde definimos los valores de la variables en cada corrida.

Esquema del escenario: Comprar último café
Dado que hay <CantidadRestanteDeCafe> café que quedan en la máquina
Y he depositado <MontoADepositar> $
Cuando presiono el botón de café
Entonces <CantidadDeCafeARecibir>café debería ser servido
Ejemplos:
|CantidadRestanteDeCafe|MontoADepositar|CantidadDeCafeARecibir|
|          1                                   |             1                 |                  1                          |
|          99                                |              99             |                  99                       |

En este caso el mismo Scenario se ejecutara dos veces, la primera con el valor 1 y la segunda vez con el valor 99.
Así que Gherkin nos sirve para documentar y para automatizar lo que luego se convertirá en test, haciéndolo con un lenguaje que puede entender negocio, o cualquier product owner, y que además puedes usar en otros idiomas más allá del inglés, hasta la fecha en 40 idiomas.

Comentarios

Publicar un comentario