Escenarios malos
En resumen: Un mal escenario puede pasar y aun así hacer daño: un recorrido largo con muchos pasos «Cuando», un escenario que depende del anterior, una comprobación de un campo de la base de datos en lugar de lo que ve el cliente, botones y colores, «Y» con detalles que no importan. Cada uno tiene su arreglo: dividirlo, darle su propio comienzo, comprobar lo visible, quedarse con lo que importa.
Problema
Doscientos escenarios que nadie lee
El equipo tiene 200 escenarios. Tardan 40 minutos en ejecutarse. Anoche falló uno: «El recorrido completo del cliente», 26 pasos. Falló en el paso 19.
El programador pasa media hora leyéndolo. Resulta que el error está en el código promocional, y el escenario trata del carrito. Mientras tanto fallan otros tres escenarios, porque dependen del mismo carrito de «El recorrido completo».
Todos los escenarios pasaban antes. Pero no ayudaban.
La idea
Cinco olores conocidos
Algunos tipos de escenarios aparecen en todos los proyectos. Se llaman «olores» (smells): algo va mal, aunque pase.
| Olor | Cómo se ve | Por qué duele | Arreglo |
|---|---|---|---|
| un recorrido largo | muchos pasos «Cuando» y «Entonces» uno tras otro | cuando falla, nadie sabe qué comportamiento está roto | cada comportamiento es un escenario propio |
| escenarios acoplados | un escenario sin comienzo que depende del anterior | ejecutado solo o en otro orden, falla | cada escenario lleva su propio «Dado» |
| comprobar el interior | «Entonces en la tabla orders…», «Entonces se llama al servicio…» | se rompe cuando cambia el código aunque la regla no haya cambiado | comprueba lo que ve el cliente |
| detalles de la pantalla | botones, colores, campos, segundos | se rompe con cada diseño nuevo | pasos declarativos |
| «Y» por todas partes | ocho líneas de «Y» con nombres, direcciones, teléfonos | lo importante se pierde entre lo que no lo es | deja solo aquello de lo que depende el resultado |
Ya has visto algunos en la lección sobre escenarios declarativos. Aquí arreglarás los dos más frecuentes.
Pruébalo
¿Qué olor es?
Ejercicio
El recorrido
1. El carrito. El editor contiene un escenario que llena el carrito paso a paso.
Divide el recorrido en dos escenarios con un solo «Cuando» cada uno: la décima unidad se acepta, la undécima se rechaza. Cada uno debe partir de su propio carrito y cazar los cuatro errores.
Solución
Característica: Como mucho 10 unidades de un producto
Escenario: La décima unidad se acepta
Dado un carrito con 9 unidades del producto
Cuando añado 1 unidad
Entonces en el carrito hay 10 unidades del producto
Escenario: La undécima unidad se rechaza
Dado un carrito con 10 unidades del producto
Cuando añado 1 unidad
Entonces no se permite añadir
Y en el carrito hay 10 unidades del producto
Los dos escenarios empiezan justo en el punto interesante: 9 unidades y 10 unidades. No hace falta llenar un carrito desde cero para comprobar el límite. Después del rechazo comprueba también qué queda en el carrito: sin esa comprobación se escapa el sistema que vacía el carrito al rechazar.
La idea
Cada escenario desde cero
Los escenarios se ejecutan por separado. Cada uno empieza con un sistema vacío: sin carrito, sin cliente, sin nada del anterior. Las herramientas pueden ejecutarlos en otro orden, solo uno, o varios a la vez.
Por eso un escenario que depende del anterior es una trampa. En el archivo parece estar bien, porque lees de arriba abajo. Pero ejecutado solo, no tiene de dónde partir.
Ejercicio
Los escenarios acoplados
2. Después un pedido de 50 €. El segundo escenario no tiene comienzo.
Ejecuta los escenarios y mira por qué falla el segundo en el sistema correcto. Después arréglalo para que pueda ejecutarse solo.
Solución
Característica: Envío gratis
Escenario: Un pedido pequeño
Dado un carrito de 49,99 €
Cuando hago el pedido
Entonces el envío es de 4,90 €
Escenario: Un pedido de 50 €
Dado un carrito de 50,00 €
Cuando hago el pedido
Entonces el envío es gratis
Ejecutado solo, el segundo escenario no tiene carrito. En el archivo parecía continuar el primero, pero cada escenario empieza de cero. Con «Dado un carrito de 50,00 €» lleva su propio comienzo y puede ejecutarse en cualquier orden.
La idea
Interior y detalles
Los otros dos olores se arreglan de la misma manera: compruebas lo que ve el cliente.
# language: esCaracterística: Envío gratis
Escenario: Envío por debajo del límite Dado un cliente llamado María García Y la dirección calle Mayor 5, Madrid Y el teléfono 600 123 456 Y un carrito de 49,99 € Cuando hago el pedido Entonces el campo delivery_fee de la tabla orders es 490 Y el botón «Pagar» es verdeLo importante aquí son dos líneas: el importe y el envío. El nombre, la dirección y el teléfono no afectan al envío, pero tienes que leerlos para entenderlo. El campo de la base de datos es correcto hoy, pero mañana el coste podría guardarse en euros y no en céntimos. Y el botón es diseño.
El escenario arreglado son tres líneas: un carrito de 49,99 €, hago el pedido, el envío es de 4,90 €. Los detalles no desaparecen del sistema. Simplemente no forman parte de este comportamiento.
Más precisamente, para curiosos
La palabra «olor» viene de los code smells del libro de Martin Fowler sobre refactorización (1999), donde Kent Beck y Fowler describen señales de código que funciona pero es difícil de cambiar. Para los escenarios los nombres no están normalizados: distintos libros los llaman de forma ligeramente distinta.
La referencia de Gherkin de la documentación de Cucumber da una vara de medir: unos antecedentes de más de 4 líneas probablemente contienen detalles que deberían ser pasos de nivel más alto. Lo mismo vale para un «Dado» largo con muchos pasos «Y».
«Comprobar el interior» no significa que la base de datos no se pruebe nunca. Las pruebas de componentes y de integración comprueban justo eso, y tienen su lugar en el módulo sobre niveles de prueba. Pero un escenario de Gherkin es una prueba de aceptación: habla del comportamiento que acepta el negocio.
Test