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

Continuando con la segunda parte del post (te dejo aquí el enlace a la primera parte), voy a dejaros las últimas buenas prácticas a la hora de escribir buenas Feature que yo considero muy importantes.
Así que continúo…

6. Evitar el uso de conjunciones en un mismo Paso

Cada paso debe hacer una cosa. Cuando hay un mismo paso que contiene dos acciones separadas mediante una “y” probablemente tendrás que dividirlo en dos Steps diferentes. El tener una acción en cada paso aumenta la capacidad de reutilización. Esta no es una regla general, puede haber en un mismo Step dos acciones, sin embargo, la mayoría de las veces es mejor evitarlos.

7. Escribir una narrativa

Las narrativas describen en aproximadamente una frase lo que una Feature hace o de lo que trata. Normalmente contienen un beneficio para el usuario, un rol y una función del mismo. Las narrativas son importantes para saber qué va a implementar esa Feature en primer lugar. También contienen una breve descripción de la función para que otros usuarios que la lean obtengan un conocimiento aproximado de qué se trata sin leer los Scenarios.

8. Given, When, Then (pasado, presente, futuro)

De manera resumida, se utiliza Given para indicar el contexto donde ocurre el Scenario, When para indicar cómo interactuar con el sistema y Then para comprobar que el resultado es el que se espera:

  •    Given <a context>: El Step Given se utiliza para describir el contexto inicial del sistema, describe las condiciones previas para la prueba. Por lo general es algo que sucedió en el pasado, por lo que se suelen expresar en pasado, para que sea más obvio indicar estas acciones.
  •    When <something happens>: El Step When se utiliza para describir un evento o una acción, por ejemplo una persona que interactúa con el sistema, en este caso escribiremos el evento en presente.
  •    Then <you expect some outcome>: El propósito del Step Then es observar los resultados, por lo que se utiliza para describir los resultados o resultados esperados, por lo que escribiremos el Step en futuro.

Cuando no se tiene mucha experiencia con BDD, un fallo habitual es mezclar el When con el Then, una manera fácil de no hacerlo es usando los tiempos verbales.

9. Usar los Background de manera coherente

Si utilizamos los mismos Steps en el comienzo de todos los Scenarios de una Feature, lo ideal es quitar esos Steps de los Scenarios y ponerlos bajo la sección de Background de la Feature. Los Background se ejecutan antes de cada Scenario. Pero hay que tener cuidado de no poner demasiados Steps en el Background pues pueden llegar a ser difíciles de entender y de mantener.

10. Escribir historias con estilo: estilo imperativo vs estilo declarativo

Los Scenarios deben ser escritos tal y como un usuario podría describirlos (estilo declarativo). Cuidado con los Scenarios que describen solamente hacer clic en enlaces y rellenando los campos del formulario, o de pasos que contienen código o selectores CSS (estilo imperativo).
El estilo imperativo es sólo otra variante de la programación, pero ciertamente no es una descripción de la necesidad (como cuando lo escribimos en estilo declarativo). En cualquier caso…
El estilo imperativo usa Steps altamente reutilizables que resume gran parte de la interfaz de usuario. Esto une el Scenario a esa interfaz y requiere más decisiones de diseño realizados por front.
Debido a la granularidad de los Scenarios, estos se vuelven muy frágiles, ya que están sujetos a cambios en los requisitos del cliente. Si, por ejemplo, se añade un nuevo campo, debe actualizar el Scenario para reflejarlo, a pesar de que el objetivo subyacente del Scenario no haya cambiado.

Ejemplo de una Feature escrita en Estilo Imperativo
Ejemplo de una Feature escrita en Estilo Imperativo

El estilo declarativo está más alineado con las historias de usuarios.
La primera cosa que debemos observar de este estilo es que la cantidad de Steps es menor que en el estilo imperativo, lo que es algo bueno (puedes ver un ejemplo de Feature escrito en este estilo más abajo). El estilo imperativo tiende a producir Scenarios con muchos Steps.
Con el estilo declarativo el objetivo del Scenario sigue siendo claro. Cuando se añade un nuevo Step, el Scenario no tiene que ser modificado.
 Ejemplo de una Feature escrita en Estilo declarativo
Ejemplo de una Feature escrita en Estilo declarativo

¿Cuál debo elegir?

Aunque creo que el estilo declarativo tiene muchos puntos fuertes es posible que no siempre sea la mejor opción para todas las situaciones. El estilo imperativo no se debe descartar por completo, si se usa con prudencia en el Scenario se pueden poner ciertos aspectos de la funcionalidad y mejorar así la comunicación.
También es importante darse cuenta de que los dos estilos no son mutuamente excluyentes. Los estilos se pueden mezclar lo largo de una aplicación, una Feature, e incluso un Scenario individual para proporcionar el nivel adecuado de granularidad según requiera la situación.
Uno de los factores más importantes para decidir qué estilo utilizar (aparte de por el mantenimiento o la duplicación de código) es el cliente. Las Feature tienen el propósito de facilitar la comunicación entre el negocio, desarrollador y tester sobre el valor del negocio y la funcionalidad:

  • Si la necesidad de los interesados está en los campos de un formulario se indica  en el Scenario con el fin de tener la confianza en el sistema (por parte de los clientes), usando así el estilo imperativo. 
  • Si las especificaciones son sólo para el desarrollador, si bien estas historias pueden estar actuando como pruebas de integración para el desarrollador que no es el propósito original, pero necesitan ser entendidas por una audiencia más amplia que desarrolladores, para alcanzar un entendimiento entre todas las partes interesadas, entonces usaremos un estilo declarativo.

A esto, al igual que en la mayoría de las áreas de desarrollo software, no existe una respuesta correcta, al final solo depende de la situación.

Para concluir…

Existen numerosas formas de escribir Features haciendo uso de Gherkin, yo en esta serie de dos post, he querido dejarte algunas buenas prácticas. La lista que os he dejado no es exclusiva, pero he querido sintentizar en 10 puntos algunas que yo creo claves a la hora de escribir Features.
Si tienes más buenas prácticas que te hayan servido a ti y quieras compartirlo con la comunidad te lo agradeceremos todos, puedes dejarlas en un comentario, y espero que sigáis alguna de estas prácticas que yo os dejo. =)

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.

2 comentarios en “Gherkin y 10 buenas prácticas a tener en cuenta a la hora de escribir Features (Parte 2)”

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *