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.
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.
¿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. =)
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Muchas Gracias María.
Muy buenas y útiles estas mejores prácticas 🙂
Por qué utilizas más de un And en el ejemplo imperativo, hasta mi conocimiento es errado. En el ejemplo declarativo utilizas dos Then seguidos, deberían ser un Then y en el siguiente renglón un And.
Sigue asi, dando buenos aportes , graciaa
Gracias por tu post, estoy iniciandome con el uso de Gherkin inicialmente solo para mejorar las historias de usuario, espero que a futuro me ayude con las pruebas!! Saludos!