Documentación viva
En resumen: Un documento de Word se queda anticuado en silencio. Los escenarios se ejecutan con cada cambio y fallan en cuanto el sistema deja de hacer lo que dicen: eso es documentación viva. Se escriben antes del trabajo, por los tres amigos: negocio, programador y QA. BDD es esa conversación. Los escenarios escritos solo por QA después del código son simplemente pruebas con más trabajo.
Problema
El documento que miente en silencio
Una persona nueva del equipo abre la especificación del envío. Un documento de Word de hace dos años. Dice: «envío gratis para más de 40 €».
La tienda da el envío gratis desde 50 €. Alguien cambió la regla, pero no el documento. Nadie lo notó, porque el documento no hace nada: está ahí sin más.
Ahora la persona nueva no sabe cuál tiene razón: ¿el documento o el sistema?
La idea
Documentación que se ejecuta
Los escenarios de este módulo son a la vez un documento y una prueba. Si la regla cambia en el sistema pero no en el escenario, el escenario falla en la siguiente ejecución. Si cambia en el escenario pero no en el sistema, también falla. Los dos no pueden separarse en silencio.
Esto se llama documentación viva. Está viva con una condición: los escenarios se ejecutan con cada cambio, normalmente de forma automática. Los escenarios que nadie ejecuta se quedan anticuados igual que el documento de Word.
Para ser documentación, el archivo debe además leerse como tal:
- Característica dice qué describe el archivo, y la propia historia puede ir debajo;
- Regla es cada regla de negocio, con las palabras del dueño;
- debajo de cada regla están los ejemplos: escenarios y esquemas con números concretos.
# language: esCaracterística: Envío gratis Como cliente quiero envío gratis en un pedido mayor para no pagar 4,90 € de envío.
Regla: Un carrito vacío no se puede pedir
Ejemplo: Un carrito sin productos Dado un carrito vacío Cuando hago el pedido Entonces el pedido se rechazaEl texto bajo «Característica» no es un paso. Es una descripción: Gherkin lo salta al ejecutar, y las personas lo leen.
La idea
Quién los escribe y cuándo
Los escenarios no los escribe una sola persona. Salen de una conversación entre tres personas que ya conociste en el Example Mapping. Se llaman los tres amigos (three amigos):
- el negocio (el dueño o el analista) expone las reglas y lo que importa;
- el programador pregunta cómo se construirá y qué es difícil en ello;
- QA pregunta «¿y si…?»: los límites, el carrito vacío, el rechazo.
¿Y cuándo? Antes del trabajo. Un escenario escrito antes del código dice lo que se quiere. Un escenario escrito después del código describe lo que se construyó, errores incluidos.
La documentación de Cucumber llama a los tres pasos descubrimiento (discovery, una conversación sobre ejemplos concretos), formulación (formulation, los ejemplos se escriben de modo que puedan ejecutarse y el negocio los confirma) y automatización (automation, el programador enlaza los pasos con el sistema). El tercer paso tiene más adelante su propio módulo.
Pruébalo
De la historia al documento
Ordena el camino desde la historia hasta la documentación viva.
En cada cambio posterior los escenarios se ejecutan de nuevoEl negocio lee los escenarios y dice «sí, es esto»Los tres amigos exponen reglas, ejemplos y preguntasEl programador enlaza los pasos y construye la característicaLos ejemplos se escriben como escenarios de GherkinEl dueño trae la historiaLos escenarios pasan y la historia está terminada
La conversación va antes de los escenarios, y los escenarios van antes del código. El negocio los confirma antes de que empiece el trabajo: ahí es cuando una corrección sale más barata. La última línea es lo que los mantiene vivos.
La idea
BDD frente a «pruebas de Gherkin»
Todo esto tiene un nombre: BDD (behaviour-driven development, desarrollo guiado por el comportamiento). Lo importante de BDD no es Gherkin. Es este orden: conversación, ejemplos, después código.
Muchos equipos toman solo la sintaxis. QA escribe los escenarios solo, después del código, con «haz clic en el botón». El negocio nunca los lee. Son pruebas de Gherkin: pruebas automáticas corrientes con una capa más encima que hay que mantener. Se paga el coste de BDD y falta el beneficio.
Señales de que esto está pasando:
- nadie del negocio ha leído los escenarios;
- los escenarios se escriben después del código;
- los pasos hablan de botones y campos, no de reglas;
- los escenarios se arreglan cuando fallan, sin preguntar si se equivocó el sistema.
Si no hay conversación, la opción honesta es una prueba de componente normal. Es más rápida y más barata. Gherkin compensa cuando el negocio lee de verdad los escenarios.
Pruébalo
¿BDD o no?
Ejercicio
El documento del envío
Toda la característica. La historia y las reglas están escritas.
Bajo cada regla, pon los ejemplos que la muestran: alrededor del límite, lejos de él y el carrito vacío. El documento tiene que cazar los seis errores.
Solución
Característica: Envío gratis
Como cliente
quiero envío gratis en un pedido mayor
para no pagar 4,90 € de envío.
Regla: El envío es gratis desde 50,00 € inclusive, y en otro caso cuesta 4,90 €
Esquema del escenario: Un pedido de <importe> €
Dado un carrito de <importe> €
Cuando hago el pedido
Entonces el envío es de <envío> €
Ejemplos: Alrededor del límite
| importe | envío |
| 49,99 | 4,90 |
| 50,00 | 0,00 |
Ejemplos: Lejos del límite
| importe | envío |
| 12,00 | 4,90 |
| 150,00 | 0,00 |
Regla: Un carrito vacío no se puede pedir
Ejemplo: Un carrito sin productos
Dado un carrito vacío
Cuando hago el pedido
Entonces el pedido se rechaza
Este archivo se le puede dar a una persona nueva en lugar del documento de Word. La historia dice por qué, las reglas dicen qué, y los ejemplos muestran exactamente dónde está el límite. Dos bloques de Ejemplos bajo un mismo esquema separan los casos alrededor del límite de los lejanos, y sus nombres dicen por qué están. Y como se ejecuta, no puede quedarse anticuado en silencio.
Más precisamente, para curiosos
ISTQB CTFL v4.0.1. La sección 2.1.3 («Testing as a Driver for Software Development») pone juntos TDD, ATDD y BDD: los tres definen las pruebas antes del código y aplican el principio de las pruebas tempranas. Sobre BDD dice que los casos de prueba se escriben en una forma sencilla de lenguaje natural que entienden las partes interesadas, normalmente Given/When/Then, y después se convierten en pruebas automáticas. La sección 4.5.3 describe ATDD (acceptance test-driven development, desarrollo guiado por pruebas de aceptación): un taller de especificación donde se discuten juntos la historia y sus criterios (cliente, programador, tester), después los casos de prueba, primero los positivos, luego los negativos y luego los no funcionales. Cuando están en un formato que entiende un marco de automatización de pruebas, las pruebas de aceptación se convierten en requisitos ejecutables.
ISTQB CT-AcT v1.0 (pruebas de aceptación) tiene un capítulo sobre las pruebas de aceptación colaborativas y trata los criterios de aceptación y las pruebas de aceptación como trabajo compartido del análisis de negocio y las pruebas.
Dan North describe BDD en el artículo «Introducing BDD», publicado por primera vez en la revista Better Software en marzo de 2006. En él, él y Chris Matts crean una plantilla para los criterios de aceptación como escenarios: Given (el contexto), When (el evento), Then (los resultados).
Los tres amigos. El nombre se usa mucho en la comunidad ágil. A menudo se vincula con George Dinwiddie, pero no encontramos una fuente primaria que lo confirme.
La documentación de Cucumber («Behaviour-Driven Development») describe las tres prácticas: Discovery, Formulation y Automation.
Test