Cuando hablamos de BDD nos viene a la mente una “forma de automatizar tests”, pero en realidad Behaviour Driven Development va mucho más allá. Esta práctica de ingeniería comprende técnicas y herramientas que aplicamos desde el momento en que levantamos los requerimientos de nuestro producto (no de nuestro test sino de nuestro producto).

Ciertamente, definimos requisitos de forma más “testeable” pero nuestros objetivos al implementar BDD son “Build the right software” y “Build the software right“.

Casi ningún software que creamos es aislado, éste es parte de una estrategia de negocio y como tal, debe estar alineado a los objetivos del negocio. “Building the right software” se trata de construir el software correcto, el que va a cumplir con las expectativas del usuario y que va a resolver su problema/necesidad y que está perfectamente alineado a los objetivos del negocio.

“Building the software right” se trata de construirlo bien, con las mejores prácticas y asegurándonos que está correctamente diseñado y desarrollado, eso no dará software más confiable y efectivo.

En este artículo veremos cómo llevar nuestros ejemplo y Gherkin al código fuente, usando Javascript, webdriverIO y Cucumber.

Si eres de los que prefiere un video, puedes verlo aquí

 

Para ver más de qué es BDD, cómo definir requerimientos y cómo usarlos como documentación, lee aquí 

 

De ejemplos a Gherkin (Given / When / Then)

Imagina que somos un banco, y queremos implementar el feature “Purchase a foreign currency cash“.

Cuando tenemos nuestros ejemplos (definidos en workshop de requerimientos y armamos nuestro example mapping), diseñamos nuestro escenario de test. Cada escenario tiene pasos que expresamos en lenguaje Gherkin: Given, When, Then, And, and But.

Gherkin es un lenguaje no técnico que puede ser leído por cualquier persona (como lenguaje natural) y que nos permite expresar comportamientos.

Los pasos más importantes son:

  • Given: son las precondiciones para un escenario y preparación del ambiente para ejecutar nuestro test.
  • When: la acción a realizar por el usuario (la acción que vamos a testear).
  • Then: el resultado esperado. ¿Cuál es la respuesta que esperamos de parte del sistema?

Siguiendo con nuestro ejemplo del banco y de nuestros clientes que quieren comprar moneda extranjera, diseñamos este escenario:

Nuestro ejemplo con data de ejemplo en lenguaje Gherkin:

Luego escribimos el test de forma más genérica, separando la data y convirtiéndola en variables que nos van a permitir correr el mismo test con distintos data set:

De Gherkin al código (scenarios, steps, step definitions)

Cuando tenemos nuestros tests escritos en Gherkin, podemos convertirlos en especificaciones ejecutables (código fuente). De esta forma podemos automatizar nuestros criterios de aceptación.

Para lograr estas especificaciones ejecutables, usamos:

  • Feature file
  • Page Object Model
  • Step definitions

Feature File

Cada escenario de testing es un feature file. Cada línea de nuestro feature file es un step.

 

Page Object Model

El page Object Model es un patrón de diseño de software que nos permite mapear todas nuestras páginas convirtiéndolas en clases, agrupar todos los selectores y funciones específicas de cada página de nuestro system under test. Este es el Javascript (en este ejemplo) que va a ejecutar las pruebas.

Muchos otros lenguajes de programación pueden ser usados, los más populares son Java, Python y Javascript.

 

Step Definitions

Step definitions son todos y cada uno de los steps de nuestro feature.

Para el step (escrito en Gherkin):

nuestro step definition (escrito con Javascript) es:

 

El test corre tantas veces como ejemplos tenemos (en este caso, correrá 3 veces):

 

Aquí puedes ver el código, descargarlo y correr los tests.

 

Conclusiones

Testeamos comportamiento (features y/o bugs), no componentes ni clases. Pero ésto no significa que no haremos test unitarios (de eso se encargan los desarrolladores). Debemos ver la calidad de nuestros productos como un “todo”.

“El todo es más que la suma de las partes”. Test que testean el comportamiento esperado de nuestros sistemas (productos) no es suficiente para lograr la calidad total.

BDD nos ayuda a pensar e implementar esa calidad total “Building the right software” y “Building the software right“.

 

Referencias

Libro BDD in Action. John Ferguson Smart.

Libro Learning Behaviour Driven Development with Javascript. Enrique Amodeo.

Web Zerobank (utilizada en los test automatizados)

Código fuente BDD Currency