Gherkin y 10 buenas prácticas a tener en cuenta a la hora de escribir Features (Parte 1)

Estos últimos meses hemos estado muy liados con el tema del Testing Ágil (te dejo aquí un post sobre cómo enfocar el Testing de forma ágil) sobre todo por la necesidad que vemos en las empresas y con el Testing Ágil, BDD para el desarrollo de software de una manera más ágil y con mayor calidad.
Cuando hacemos BDD, empezamos escribiendo historias de usuario (lo que vamos a llamar Features) usando el DSL Gherkin por lo que estamos empezando el Testing desde negocio y la toma de requisitos. Aquí la comunicación entre el Product Owner con desarrollo y testers es fundamental.
Una de las mayores dudas que pueden surgir al respecto es cómo escribir nuestras Features. En este post os quiero dejar una serie de buenas prácticas (en concreto 10) para escribir buenas Features, los más eficientes, legibles y mantenibles posibles.
Después de leer este post (y teniendo conocimientos de Gherkin), deberías saber escribir Features más allá de escribir líneas escritas en Gherkin. Así que, vamos allá.

1. Las Feature deben probar partes o funcionalidades de una App y no la App al completo

Una Feature (o característica en español) representa una funcionalidad del software que se quiere construir, características que piden los usuarios, por eso se les da ese nombre. Por ejemplo, “Reservar un vuelo” representaría una Feature.
Es una parte del software final que funciona y que además será de gran valor para los usuarios y se relaciona estrechamente con lo que los usuarios piden.

2. Usar el mismo idioma que los clientes

Gherkin es un lenguaje, un DSL, muy cercano al lenguaje natural. A día de hoy, existen unos 60 idiomas aproximadamente en los que poder utilizar Gherkin para facilitar la comunicación entre negocio, desarrollo y testers. Si no se especifica el idioma, tomará por defecto el inglés.
Si quieres usar un idioma específico simplemente, en la primera línea de la Feature, tendrás que poner #language <código idioma>, por ejemplo en español #language es.
Usando el lenguaje que hablen los clientes, será más fácil la comunicación con ellos.

3. Organizar las Feature

Una forma útil de organizar los Scenarios (te dejo un post donde se explican los Scenarios) es, por ejemplo, por la rapidez con que se ejecuten. Se puede utilizar 2 o 3 niveles de granularidad para esto:
– Fast: en este nivel pondremos aquellos Scenarios que se ejecutan muy rápido, por ejemplo por debajo de un décimo de segundo.
– Slow: en este nivel tendremos aquellos Scenarios que son más lentas que “fast”, pero no extremadamente lentas, así como por ejemplo de un segundo.
– Glacial: en este nivel tendremos aquellos Scenarios que se toman un tiempo largo para ejecutarse.
No tienes por qué seguir esta organización o división, puedes usar la organización que mejor se adecúe a vosotros, ponerlos en subdirectorios separados, usar etiquetas (como vemos en el siguiente punto), etc.

4. Usar etiquetas

Las etiquetas son una muy buena forma de agrupar y organizar los Scenarios y las Feature. Son cadenas y se puede colocar tantas etiquetas como se desee por encima de funciones o de palabras clave como Scenarios, Scenarios Outline o Examples.
Para añadir una etiqueta basta con poner el símbolo @ y el texto que se desee. Por ejemplo podemos organizarla con etiquetas como @small @medium y @large  o tal vez @hare, @tortoise y @sloth.
Un Scenario o Feature puede tener tantas etiquetas como se quiera o necesite, simplemente basta con separarlos con espacios. El uso de etiquetas permiten mantener los Scenarios de una Feature juntos, y ejecutarlos por separado.
La ventaja de separarlos de esta manera es que se puede ejecutar los Scenarios seleccionándolos por etiquetas, es decir, ejecutar los Scenarios más rápido con más frecuencia o ejecutar los Scenarios muy grandes o lentos durante la noche.
Las etiquetas tienen usos más allá que la separación de Scenarios en grupos:
– Cuándo se deben de ejecutar: por ejemplo usando etiquetas como @checkin @hourly o @daily
– Las dependencias externas que tienen: usando etiquetas como @local, @database o @network
– Nivel: con etiquetas como por ejemplo @functional, @system o @smoke
Y así todas las que se te vayan ocurriendo para tener bien organizados tus Scenarios.

5. Escribir Scenarios lo más Independientes posible

Lo ideal es que no haya ningún tipo de acoplamiento e independencia entre los Scenarios, que sean lo más independientes y autónomos unos de otros. De no ser así podría crear problemas si, por ejemplo, el orden de ejecución de los Scenarios se modifica o se ejecutan en paralelo.
Por ejemplo, un Scenario podría ser pasar a través de un registro a una base de datos y los Scenarios posteriores dependerán de la existencia de ese registro. Esto puede funcionar, pero en un futuro creará un problema de mantenibilidad, mala deuda técnica, etc.

Terminando…

Hasta aquí el post de hoy, he querido dejar solo algunas para que no se me hiciera más largo, y dejar otras el resto para una segunda parte. Espero que os sirva de ayuda y… ¡A escribir buenas Feature!
 

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023