BDD para la automatización de pruebas

En la actualidad en muchas de las empresas del mundo digital en las que se desarrolla software, se habla de la  Automatización de pruebas, esto con la finalidad de sacar productos más rápidos, reducir errores, procesos automáticos y muchos otros motivos. Probablemente cuando se abarca este tema lo primero que nos preguntamos es ¿Porque deberíamos hacerlo,  quién debería hacerlo y cómo hacerlo?, por ello hablaremos de BDD y algunas de las cosas que se pueden realizar.

¿Qué es BDD (Behavior Driven Development)?

Este se refiere a desarrollo dirigido por comportamientos, BDD no se trata de una técnica ni tampoco una herramienta de testing, sino que se trata de una estrategia de desarrollo, que se enfoca en prevenir defectos en lugar de encontrarlos en un ambiente controlado.

¿Qué es Automatización de pruebas?

Por definición, las pruebas automatizadas son aquellas que se ejecutan sin requerir la intervención de una persona. En el articulo sobre Selenium WebDriver podremos encontrar información sobre la herramienta de automatización Selenium y algunas particularidades para tener en cuenta a la hora de la automatización de pruebas.

Hoy en día, BDD es una estrategia que encaja muy bien en las metodologías ágiles, ya que en estas generalmente los requerimientos son entregados como HU’s (Historias de usuario). Lo que se plantea a través del desarrollo dirigido por comportamientos es la definición de un lenguaje común para el negocio y equipo solucionador.

Con BDD las pruebas de aceptación podrían ser escritas directamente en lenguaje Gherkin sin ningún problema, ya que este es un lenguaje común el cual lo puede escribir alguien sin conocimientos en programación, lo normal es que este se encuentre escrito en inglés, aunque algunas personas que no tienen dominio del inglés lo hacen en el idioma que mejor dominan. A continuación, un ejemplo de lenguaje Gherkin tomado de Cucumber.

El lenguaje Gherkin no es más que texto con una estructura de 5 palabras claves con las que construimos sentencias y con estas describimos las funcionalidades. Este texto se guarda en un archivo con la extensión “.feature”, las palabras claves que normalmente se utilizan son:

• Feature: Nombre de la funcionalidad que vamos a probar, el título de la prueba (HU).
• Scenario: por cada prueba que se ejecutara se especifica la funcionalidad a probar.
• Given: Este sería el contexto del escenario de prueba o las precondiciones de los datos.
• When: Se especifican el conjunto de las acciones que se van a ejecutar en el test.
• Then: Aquí se especifica el resultado esperado del test y/o las validaciones que deseamos realizar.

¿Qué herramientas permiten lenguaje Gherkin?

Las herramientas Cucumber o JBehave, permiten implementación de una capa de conexión entre lenguaje Gherkin y la interfaz de usuario que se desea probar, pudiendo así utilizar eso como los pasos de una prueba automatizada.

Una de las principales características cuando hacemos BDD con Cucumber es que los escenarios de prueba a la funcionalidad se escriben mucho antes de la elaboración del código de una prueba automatizada. Cuando se escribe en lenguaje Gherkin sobre Cucumber se utilizan ejemplos concretos de lo que queremos que haga el software y a medida que se escriben los escenarios, estos asumen un papel importante como documentación del proyecto y documentación sobre las pruebas automatizadas.

Pasos para escribir lenguaje Gherkin con cucumber:

1. Crear un archivo con extensión “.feature”  ejemplo “is_it_Friday_yet.feature”
2. Redactamos la HU con las palabras claves:
   
   Feature: Search for an ítem
   To check an item price and add them to shopping cart
   as an online customer
   user should be able to search for an ítem
   
   
3. Redactamos el/los escenarios asociados a esta HU con las palabras claves:

Scenario: Search products from navigation-menu
Given that Fray wants to buy Sweater
When He searches for Sweater using the navigation menú
Then He should see the list of Sweaters with prices available for sale

Si se ejecuta este fragmento de código en un ide como eclipse podemos ver que este nos genera la definición de los pasos presionando la tecla F11 en la consola de la siguiente manera:

You can implement missing steps with the snippets below: 

@Given("^that Fray wants to buy Sweater$")
public void that_Fray_wants_to_buy_Sweater() throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
@When("^He searches for Sweater using the navigation menú$") public void He_searches_for_Sweater_using_the_navigation_menú() throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
@Then("^He should see the list of Sweaters with prices available for sale$")public void He_should_see_the_list_of_Sweaters_with_prices_available_for_sale() throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

Para finalizar, con el uso del lenguaje gherkin se puede generar documentación de evidencia, hacer uso de este fragmento de código el cual puede ser implementado para realización de una prueba E2E o en una prueba unitaria, ya que podemos realizar el paso a paso de la prueba sobre esa historia de usuario con la ejecución de cada método o si solo se deseamos comprobar el resultado final de la prueba.