Qué, no cómo
En resumen: Un escenario dice qué hace el sistema, no cómo se hace clic por la pantalla. «Haz clic en el botón Pedir» se rompe con cada cambio de diseño aunque la regla siga igual. Un escenario comprueba un comportamiento: un solo «Cuando». Las palabras son las del negocio: carrito, pedido, envío, no tablas ni URL.
Problema
Cuarenta escenarios y un botón
La tienda cambia el diseño del carrito. El botón «Pedir» pasa a ser «Ir al pago» y se mueve a otra línea. En las reglas no ha cambiado nada.
A la mañana siguiente fallan 40 escenarios. Todos son sobre el envío, y todos empiezan así:
# language: esCaracterística: Envío gratis
Escenario: Envío por debajo del límite Dado que abro el sitio web de la tienda Y pongo una taza de 49,99 € en el carrito Y abro el carrito Cuando hago clic en el botón «Pedir» Entonces en la parte inferior de la pantalla dice «Envío: 4,90 €»El dueño tampoco puede leerlos. Busca la regla del envío y ve botones.
La idea
Qué, no cómo
Este escenario dice cómo hacer clic por la pantalla. Por eso se llama imperativo: una serie de órdenes. El mismo ejemplo, contado como qué hace el sistema, es declarativo:
# language: esCaracterística: Envío gratis
Escenario: Pedido justo por debajo del límite Dado un carrito de 49,99 € Cuando hago el pedido Entonces el envío es de 4,90 €Tres líneas en lugar de cinco, y ninguna sabe de botones. Si mañana el pedido se hace por voz o desde la aplicación móvil, el escenario sigue igual. La regla no ha cambiado, así que el escenario tampoco debería cambiar.
El «cómo» no desaparece. Se traslada al código que enlaza el paso «Cuando hago el pedido» con el sistema. Allí se corrige una línea para el botón nuevo, no 40 escenarios.
Pruébalo
¿Qué o cómo?
Ejercicio
Reescríbelo
1. Sin botones. El editor contiene el escenario del principio de la lección.
Reescribe el escenario en el lenguaje del vocabulario: sin sitio web, botones ni pantalla. Añade también un ejemplo justo en el límite, para que se cacen los dos errores.
Solución
Característica: Envío gratis
Escenario: Pedido justo por debajo del límite
Dado un carrito de 49,99 €
Cuando hago el pedido
Entonces el envío es de 4,90 €
Escenario: Pedido justo en el límite
Dado un carrito de 50,00 €
Cuando hago el pedido
Entonces el envío es gratis
Los pasos sobre botones y pantallas no están en el vocabulario, así que no se pueden ejecutar. El vocabulario es el idioma que comparten el negocio y el equipo: carrito, pedido, envío. Cada uno de los dos escenarios caza un error: el límite en 50,00 € y el coste en 49,99 €.
La idea
Un comportamiento por escenario
Aquí hay otra cosa que parece ahorradora:
# language: esCaracterística: Envío gratis
Escenario: Envío Dado un carrito de 49,99 € Cuando hago el pedido Entonces el envío es de 4,90 € Dado un carrito de 50,00 € Cuando hago el pedido Entonces el envío es gratisSon dos escenarios en uno. Si falla, tienes que leer las líneas para averiguar qué comportamiento está roto. Y si falla la primera mitad, la segunda ni siquiera se ejecuta.
La regla es un comportamiento por escenario: un solo «Cuando», y el nombre expresa ese comportamiento. Si necesitas una «y» en el nombre («cancelar y reembolsar»), hay dos comportamientos.
Ejercicio
Divídelo
2. Dos en uno. En esta tarea, dos pasos «Cuando» en un escenario son un error.
Divide el escenario en dos: cada uno con un comportamiento y un nombre que lo exprese.
Solución
Característica: Envío gratis
Escenario: Por debajo de 50 € el envío se paga
Dado un carrito de 49,99 €
Cuando hago el pedido
Entonces el envío es de 4,90 €
Escenario: Desde 50 € el envío es gratis
Dado un carrito de 50,00 €
Cuando hago el pedido
Entonces el envío es gratis
Ahora cada escenario tiene un nombre que se lee como una regla: «Por debajo de 50 € el envío se paga», «Desde 50 € el envío es gratis». Cuando uno falla, el nombre dice qué se ha roto sin leer los pasos.
La idea
El idioma del negocio
Las palabras de un escenario son las del dueño y el cliente: carrito, pedido, envío, código promocional. Las mismas que en la historia y en el tablero del Example Mapping. Si el negocio dice «pedido», el escenario no dice «solicitud», y el código no dice cart_submission.
No escribimos:
- nombres de tablas y campos (
orders.delivery_fee); - URL y respuestas del servidor (
POST /api/orders,200); - nombres de funciones (
calcDelivery(4999)).
Son decisiones del equipo y cambian, mientras la regla se queda. Un escenario que las contiene se rompe por ellas, y quien conoce la regla no puede leerlo.
Más precisamente, para curiosos
La documentación de Cucumber («Writing better Gherkin») dice lo mismo: un escenario describe el comportamiento del sistema, no cómo está construido; es decir, el qué, no el cómo. No prohíbe el estilo imperativo: en algunos contextos los detalles importan, pero esos escenarios cuestan más de mantener.
¿Cuándo es el «cómo» el propio requisito? Cuando compruebas la accesibilidad del formulario de pago, el teclado y las etiquetas son el comportamiento. Entonces el escenario los dice. Pero la regla del envío no depende de un botón.
La idea de un lenguaje común para el negocio y el equipo tiene nombre en el diseño de software: el lenguaje ubicuo (ubiquitous language) del Domain-Driven Design de Eric Evans (2003). Las palabras de la conversación, del escenario y del código son las mismas.
Test