Pages Menu
Categories Menu

Posted by on Jun 10, 2016 in General | 2 comments

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. =)

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

2 Comments

  1. Muchas Gracias María.
    Muy buenas y útiles estas mejores prácticas 🙂

  2. Sigue asi, dando buenos aportes , graciaa

Post a Reply

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

Share This