Te va a interesar!

6/recent/ticker-posts

Gherkin: Qué es y cómo se usa?

Si usaron alguna vez Cucumber, habrán notado que tiene una sintaxis particular que seguir. Es muy flexible, ya que podemos escribir lo que queramos realmente, pero lo hacemos dentro de una estructura muy conocida dada por el:

Given

When

And

Then

Esto se conoce como Gherkin, y es un lenguaje que nos otorga estas palabritas clave para estructurar como les decía, nuestras especificaciones ejecutables. Qué son estas especificaciones ejecutables se preguntarán? Nuestros Features de Cucumber.

La gran mayoría de las líneas en una especificación, o Feature, van a empezar con una de estas palabras citadas arriba. Dicho sea de paso...sabían que pueden elegir diferentes idiomas para nuestros Features? Así es! El inglés es el que más conocemos, pero podemos tener nuestros Features con Gherkin en español tranquilamente.

Vamos a poder tener líneas comentadas, como en cualquier otro archivo con código, en cualquier parte del documento. Esto lo hacemos, a diferencia del // que usamos en Java, C# y otros lenguajes, con un numeral # al comienzo de la línea.

Formato de Gherkin.

El indent a usar en un archivo escrito con Gherkin puede ser cualquiera. Esto significa que no vamos a tener problemas como lo tendríamos en, por ejemplo, Python. Si es recomendado que se usen 2 espacios para los Steps relacionado con el Scenario. 

Vamos a tener, entonces, algo así:

Scenario: Esto es una demostración de Gherkin
  Given hago algo
  Then pasa algo

Lo que sigue a las palabras clave que nos provee Gherkin es enteramente a nuestra elección. Eso si, siempre recomiendo que sean coherentes a la hora de escribir los pasos. 

Si les parece magia cómo eso que escribimos a nuestro antojo puede significar algo en el código, eso es porque siempre está asociado a un bloque de código en lo que se conoce como Step Definition. Esto lo vemos en detalle en los frameworks con Cucumber que hemos creado en los Tutoriales.

Keywords.

A las palabras ya mencionadas, tenemos también otras que ayudan a dar formato a nuestras especificaciones. 

Algunas de ellas son:

  • Feature: Es la que nos va a dar la descripción más high level de lo que se está probando. La que generaliza lo que agrupamos en los Scenarios del documento.
  • Scenario Outline: A diferencia del Scenario común, en este vamos a poder especificar campos parametrizables. Para que funcione, vamos a necesitar...
  • Examples: La otra parte clave de un Scenario Outline. Acá vamos a tener una tabla con una cantidad variable de columnas en la que vamos a decir qué parámetros vamos a usar para qué campos.
  • Rule: Simple y sencillo. Acá vamos a poner qué regla del negocio estamos probando. Sirve para dar todavía más identidad a esta herramienta como BDD y que no sea simplemente algo que se usa para generar reportes sin colaboración con los BAs
  • Background: Esto va a ser el pre step de nuestros Scenarios. En el Background vamos a declarar, de la misma manera que los scenarios, pasos que van a ser ejecutados antes de cada Scenario o Scenario Outline. 
Luego vamos a tener cosas como los tags, que se usan con @ y nos van a permitir agrupar scenarios por lo que queramos, como prioridad, algún subgrupo de tests, etc. Esto va a servirnos para configurar el runner y poder ejecutar lo que queramos desde la línea de comando por ejemplo! 

Conclusión.

Como vemos, Gherkin está diseñado para que sea de fácil lectura para personas no técnicas, pero aún tomando ventaja de lo que podemos definir con código detrás de escena. Esto nos deja en una posición perfecta para tener colaboración con, por ejemplo, los Business Analysts, Devs y Testers para estar todos en la misma página sobre qué probar, cómo hacerlo y dónde.

En los tutoriales van a encontrar en detalle cómo implementar Cucumber, Gherkin y técnicas avanzadas para usarlo, no se lo pierdan!


Publicar un comentario

0 Comentarios