Curso de Drupal Behat - Desarrollo guiado por comportamiento (BDD)

Cada tipo de prueba cubre un nivel diferente del producto: las pruebas unitarias comprueban las partes más pequeñas del código, las pruebas funcionales que una característica específica hace lo que debe, y las pruebas de aceptación que el producto cumple los requisitos del negocio. Estas últimas son las que el cliente puede leer, entender y validar. También se analiza cuándo merece la pena automatizar y cuándo no.

En BDD, las pruebas se derivan directamente de los requisitos de negocio escritos en lenguaje sencillo, de modo que los equipos de negocio y técnicos parten de una comprensión compartida de cómo debe comportarse el producto. Los escenarios funcionan tanto como pruebas automatizadas como documentación viva: cuando un requisito cambia, el escenario cambia, y lo que no se actualiza no supera las pruebas.

Convertimos los requisitos abstractos en comportamientos verificables. Partiendo del formato "como… quiero… para que…", añadimos lo que hace comprobable un escenario: precondiciones, poscondiciones, escenarios alternativos y casos de error. Terminamos con la diferencia entre verificar (el sistema hace lo que dice la especificación) y validar (que eso es lo que el negocio realmente necesitaba).

Behat es la herramienta que ejecuta los escenarios: BDD es la metodología, Gherkin el lenguaje en el que están escritos los escenarios, y Behat el motor que los lee y los comprueba contra el sistema real. Encaja de forma natural en entornos PHP y es ampliamente usado en proyectos Drupal, porque hay pasos ya preparados para nodos, usuarios, permisos, formularios y vistas. Mink es lo que decide si un escenario necesita JavaScript o no.

Desglosamos un archivo .feature pieza a pieza: la feature describe la funcionalidad que se valida, el scenario un caso específico dentro de ella, y los pasos Given/When/Then las acciones y los resultados esperados. A partir de ahí, las herramientas que evitan repetirse: backgrounds para el contexto compartido, scenario outlines para ejecutar el mismo escenario con varios conjuntos de datos, y variantes para los casos de error.

Primer bloque práctico: configuramos la máquina de pruebas y escribimos escenarios sobre casos reales, desde comprobaciones básicas de acceso y errores hasta visualización de contenido, navegación y formularios, incluyendo los que dependen de JavaScript. La regla en todo momento es mantener solo los pasos que verifican un comportamiento real y descartar los decorativos.

Instalamos Behat con Composer en un entorno DDEV y repasamos los paquetes que lo hacen funcionar en Drupal: behat/behat como ejecutor, behat/mink y su extensión para interactuar con el navegador, los controladores correspondientes, y drupal/drupal-extension, que proporciona los pasos específicos de Drupal. Con eso en su lugar, la decisión práctica es cuándo un emulador sin interfaz gráfica es suficiente y cuándo es necesario manejar un navegador real.

En behat.yml se declara todo: los suites, los contextos que proporcionan los pasos disponibles, las extensiones y la URL base del entorno, con perfiles separados para no tener que tocar la configuración principal al cambiar de entorno. También se analiza dónde residen las features y los contextos dentro del proyecto, y cómo cargar los contextos de DrupalExtension junto con la biblioteca propia de Metadrop (metadrop/behat-contexts), que añade utilidades de depuración y capturas de pantalla.

Ejecutamos la suite y aprendemos a leer la salida: pasos que pasan, que fallan, que quedan pendientes porque no coincide ninguna definición, y que se omiten porque un paso anterior falló. Desde ahí puedes filtrar por etiquetas o comprobar la configuración con una ejecución en seco. Cuando ningún paso existente encaja, escribe los tuyos en el contexto del proyecto — con parámetros, apoyándose en la API de Drupal y en XPath — guardando los reutilizables en librerías compartidas en lugar de acumularlos en FeatureContext.