Pages Menu
Categories Menu

Posted by on May 27, 2016 in General | 6 comments

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!

 

María Morales

María Morales

Practitioner at 233 Grados de TI
Interesada y apasionada en todo aquello que tenga relación con metodologías ágiles y calidad software, gestión de proyectos, modelos de procesos, DevOps y sobre todo en gestión de equipos.

Actualmente, colabora activamente con la Empresa y Comunidad 233, dando formación y mentoring ágil además de organizando eventos, charlas e iniciativas para difundir el conocimiento sobre Ingeniería del Software.

Profesionalmente dedicada al mentoring ágil en 233 Grados de TI, calidad software, testing ágil, a la implantación en importantes organizaciones de Scrum, agilidad, DevOps, Product Owner, peopleware, automatización de pruebas web y móviles con BDD, Calabash.

Certificada por la Scrum Manager como Scrum Manager con credenciales de profesora, entre otras certificaciones, como por ejemplo en GIT y GitHub.
María Morales

6 Comments

  1. Hola,
    Sólo comentar que para indicar un idioma específico, a la instrucción que mencionas, le falta «:»
    Debe ser–> #language:

    Sin los dos puntos no funciona correctamente.

    Saludos!!

  2. Muchas gracias Álvaro por el detalle, no me dí cuenta de que faltaba.

    Un saludo =)

  3. Hola!

    Estoy teniendo problemas con los tags (concretamente que es como si no pusiera nada). El entorno técnico es Cucumber-Java, y seguro qu ealgo estoy haciendo mal, podríais poner algún ejemplo en este entorno técnico? me estoy volviendo loca!

    Gracias!

  4. Buenas tardes, Buen post, quisiera saber donde puedo encontrar la segunda parte?

    Gracias!!

    • La he encontrado , muchas gracias

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This