Desarrollo guiado por comportamiento (BDD): Gherkin y Cucumber

¿Qué es el desarrollo guiado por comportamiento?

El desarrollo guiado por comportamiento, o BDD por sus siglas en inglés, es una forma de crear software que describe un sistema por el comportamiento que la gente espera de él. En lugar de empezar con casos de prueba técnicos, el equipo empieza con conversaciones sobre resultados del negocio, acciones de los usuarios, reglas y ejemplos.

A Dan North se le atribuye la idea a mediados de la década de 2000, como una evolución del desarrollo guiado por pruebas. El objetivo era que las conversaciones sobre software fueran más fáciles de seguir al centrarse en el comportamiento: en esta situación, cuando alguien hace esto, debe pasar aquello. Un buen escenario de BDD lo puede leer una persona no técnica, usarlo un programador y comprobarlo un probador.

Las tres prácticas del BDD: descubrimiento, formulación y automatización

Descubrimiento es la conversación. Quienes entienden la necesidad, construyen la función y la prueban revisan ejemplos concretos antes de construir nada, para encontrar dudas mientras cuesta poco hablarlas. Para una función de citas: ¿se puede reservar fuera del horario?, ¿el personal debe aprobar?, ¿qué pasa si el horario ya está ocupado?
Formulación escribe los ejemplos acordados en un formato estructurado y en lenguaje sencillo, normalmente Gherkin, lo bastante preciso para quitar ambigüedad y legible desde fuera.
Automatización conecta esos escenarios con código que los ejecuta como pruebas, para que el equipo confirme en cualquier momento que el comportamiento sigue funcionando.

La automatización no debe reemplazar las dos primeras. Escribir scripts de prueba con Given/When/Then sin la conversación es usar el formato del BDD, no hacer BDD.

Cómo funcionan los escenarios Given/When/Then

Given (dado) fija la situación inicial, When (cuando) describe la acción o el evento y Then (entonces) dice el resultado esperado. Cada escenario cubre un solo comportamiento. Un ejemplo para la página de reservas de un pequeño negocio:

Scenario: un cliente reserva una cita disponible
Given una terapeuta tiene una cita libre el viernes a las 2:00 p. m.
And el cliente está en la página de reservas
When el cliente elige ese horario del viernes y confirma
Then la cita queda reservada para ese cliente
And el cliente recibe una confirmación

Cualquiera puede revisar si ese comportamiento es correcto sin leer código. Si después el negocio decide que el personal debe aprobar las reservas, el escenario cambia para decirlo. Un escenario que intenta cubrir reserva, pago, cancelación y correo a la vez se vuelve difícil de leer y de mantener.

Lo básico de la sintaxis Gherkin

Gherkin es el formato de texto que leen casi todas las herramientas de BDD. Sus palabras clave principales:

Feature nombra la función y puede explicar su propósito.
Rule agrupa escenarios bajo una regla del negocio.
Scenario describe un ejemplo de comportamiento.
Given, When y Then fijan el contexto, la acción y el resultado; And y But agregan pasos.
Background reúne la preparación común a varios escenarios de un archivo.
Scenario Outline con Examples ejecuta un escenario con una tabla de valores distintos.

Gherkin también se puede escribir en español con palabras clave como "Característica", "Escenario", "Dado", "Cuando" y "Entonces". El objetivo no es que los requisitos se vean formales, sino que los ejemplos sean coherentes y se puedan probar. Una función de aprobación de facturas, por ejemplo, puede tener un escenario para una factura por debajo del límite de aprobación, otro por encima y otro sin los datos obligatorios.

Cómo Cucumber ejecuta los escenarios como pruebas

Cucumber es una herramienta común para ejecutar escenarios de BDD. Lee archivos .feature escritos en Gherkin y relaciona cada paso con código de definición de pasos escrito por el equipo:

El equipo escribe un escenario en un archivo .feature.
Cucumber busca la definición de cada línea.
Cada definición hace algo: abre una página, crea datos de prueba, llama a una interfaz o comprueba un resultado.
Cucumber informa qué escenarios pasaron y cuáles fallaron.
El equipo corrige el código, la preparación de la prueba o el escenario.

Otras herramientas permiten el mismo flujo en distintos lenguajes de programación; la práctica importa más que la herramienta. La automatización también cuesta: las definiciones de pasos hay que diseñarlas, los datos de prueba hay que administrarlos y las pruebas que manejan la pantalla pueden ser lentas y frágiles. Muchos equipos automatizan solo los escenarios que protegen comportamientos importantes del negocio.

BDD frente a TDD

El desarrollo guiado por pruebas (TDD) es una práctica de programadores: escribir una prueba que falla, escribir el código justo para que pase y luego ordenar el código manteniendo las pruebas en verde. Ambos animan a pensar antes de construir y usan pruebas como retroalimentación. La diferencia está en el enfoque y el público:

Enfoque: el BDD parte del comportamiento del negocio y de ejemplos compartidos; el TDD parte del diseño de una unidad de código.
Público: el BDD incluye a responsables del producto, probadores y programadores; el TDD es sobre todo para programadores.
Formato: el BDD usa escenarios Gherkin y ejemplos de aceptación; el TDD usa pruebas unitarias en el lenguaje de programación.
Mejor uso: el BDD aclara requisitos y criterios de aceptación; el TDD ayuda a diseñar código confiable en pasos pequeños.

Funcionan bien juntos: acuerden con BDD cómo debe comportarse un flujo de aprobación de facturas y construyan con TDD las reglas de aprobación.

Cuándo ayuda el BDD y cuándo sobra

El BDD suele valer la pena cuando los requisitos se malinterpretan con facilidad o tienen muchas excepciones, cuando el negocio, las pruebas y el desarrollo necesitan un lenguaje común, cuando los criterios de aceptación son vagos, cuando construir lo equivocado saldría caro o cuando volver a probar a mano los flujos clave se ha vuelto pesado.

Por lo general sobra en cambios muy pequeños, limpieza técnica interna, demostraciones desechables o trabajo cuyo comportamiento ya es obvio, y se estanca si las personas del negocio no están disponibles para el descubrimiento. Una prueba útil: si escribir un escenario no aclara nada, no guía una decisión ni protege un comportamiento importante, use algo más ligero.

Errores comunes con el BDD

Empezar por las herramientas y no por las conversaciones. Instalar Cucumber no crea un entendimiento compartido.
Escribir escenarios técnicos. Las tablas de la base de datos, los selectores de la página y los nombres de métodos no van en un escenario.
Scripts largos de principio a fin. Un escenario por comportamiento es más fácil de leer y de depurar.
Resultados vagos. "Entonces la factura se procesa correctamente" debería decir qué ve el usuario o qué estado cambia.
Automatizar cada ejemplo. Algunos ejemplos sirven solo para la conversación.
Dejar que los escenarios se queden viejos. Cuando cambia una regla, el escenario cambia con ella.
Dejar fuera a los probadores en el descubrimiento. Ellos detectan pronto los casos que faltan y los supuestos ocultos.

Cómo empezar con BDD en una función

Elija una función con comportamiento visible y algo de incertidumbre, como reservas, aprobación de facturas, cambio de contraseña o estado de un pedido.
Reúna a alguien que conozca la necesidad del negocio, a quien la va a construir y a quien la va a probar.
Hablen de ejemplos: el caso normal, la información que falta y las excepciones que importan.
Escriban dos o tres escenarios Gherkin cortos, uno por comportamiento.
Comprueben que una persona del negocio pueda leerlos; si no, reescríbanlos.
Automaticen los que protegen comportamientos importantes, con Cucumber u otra herramienta parecida.
Actualicen los escenarios en cada cambio de la función.

Dónde encaja ASL

El trabajo de desarrollo de software a medida de ASL parte de la misma idea que el BDD: acordar la primera versión y sus ejemplos de aceptación antes de construir, elegir una versión acotada con pruebas de aceptación que usted pueda observar y revisar el software en funcionamiento con datos representativos y aprobados. No necesita saber Gherkin para participar; necesita poder decir qué debe pasar en cada situación.

Preguntas frecuentes

¿Qué es el BDD en palabras sencillas?

El desarrollo guiado por comportamiento es una forma de crear software en la que el equipo primero acuerda ejemplos concretos de lo que debe hacer, los escribe como escenarios Given/When/Then y luego los usa para guiar y probar el código.

¿Quién creó el desarrollo guiado por comportamiento?

A Dan North se le atribuye haber presentado el BDD a mediados de la década de 2000, como una evolución del desarrollo guiado por pruebas.

¿Qué diferencia hay entre Gherkin y Cucumber?

Gherkin es el formato de texto para escribir escenarios con palabras clave como Feature, Scenario, Given, When y Then. Cucumber es una herramienta que lee los archivos Gherkin y ejecuta cada paso como una prueba automatizada.

¿El BDD es lo mismo que el TDD?

No. El TDD es una práctica de programadores centrada en diseñar código con pruebas unitarias. El BDD se centra en el comportamiento del negocio y en ejemplos que pueden leer las personas del negocio, los probadores y los programadores. Muchos equipos usan los dos.

¿Necesito Cucumber para hacer BDD?

No. Las conversaciones y los ejemplos claros son la base del BDD. Cucumber u otra herramienta parecida agrega la automatización, y muchos equipos automatizan solo sus escenarios más importantes.

Guías relacionadas

Conozca el producto completo

Consulte funciones, acceso actual y límites

Desarrollo guiado por comportamiento (BDD): cómo funciona, Gherkin y Cucumber