Tema 2.5 - Buenas practicas

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

Un Feature representa una funcionalidad del software que se quiere probar, características que son realizadas por los usuarios, por eso se les da ese nombre (Feature o característica). Por ejemplo, “Reservar un vuelo” representaría un Feature.

2.  Usar el mismo idioma que los clientes

Gherkin es un lenguaje, muy cercano al lenguaje natural. A día de hoy, existen unos 60 idiomas aproximadamente en los que se puede Gherkin, para facilitar la comunicación entre negocio, desarrollo y testers. Si no se especifica el idioma, tomará por defecto el inglés.
Si se quiere 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 los features

Una forma útil de organizar los Scenarios es, por ejemplo, por la rapidez con que se ejecutan. Se puede utilizar 2 o 3 niveles:

• Fast: en este nivel se ponen aquellos Scenarios que se ejecutan muy rápido, por ejemplo, por debajo de un décimo de segundo.
• Slow: en este nivel se tendrán aquellos Scenarios que son más lentos que el punto anterior, pero no extremadamente lentos, así como por ejemplo de un segundo.
• Glacial: en este nivel se tienen aquellos Scenarios que se toman un tiempo largo para ejecutarse.

No sé tiene por qué seguir esta organización o división, se puede usar la organización que mejor se adecúe a lo que se realiza, ponerlos en subdirectorios separados, usar etiquetas (como se ve en el siguiente punto), etc.

4.  Usar etiquetas

Las etiquetas son una muy buena forma de agrupar y organizar los Scenarios y los Feature, son cadenas de texto 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 permite 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

5.  Escribir Scenarios lo más Independientes posible

Lo ideal es que no haya ningún tipo de acoplamiento o dependencia entre los Scenarios, es decir, se busca 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 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.

6.  Evitar el uso de conjunciones en un mismo Paso

Cada paso (Given, When, Then) debe hacer una cosa, cuando hay un mismo paso que contiene dos acciones se debe separar mediante un “And”. 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.  Usar los Background de manera coherente

Si se utiliza los mismos Steps en el comienzo de cada uno los Scenarios de un Feature, lo ideal es quitar esos Steps de los Scenarios y ponerlos bajo la sección de Background del Feature, los Background se ejecutan antes de cada escenario, pero se debe tener en cuenta no poner demasiados Steps en el Background ya que pueden afectar a la comprensión de los escenarios y se vuelven más difíciles de mantener.