Escribir pruebas automatizadas es un desafío común. A menudo, lo que comienza como una suite de pruebas clara y útil puede convertirse con el tiempo en un laberinto de scripts frágiles y difíciles de mantener. Behavior-Driven Development (BDD) y su lenguaje, Gherkin, prometen una solución al alinear las pruebas con el comportamiento del negocio en un lenguaje natural. Sin embargo, el verdadero poder de BDD no se desbloquea simplemente usando la sintaxis Given-When-Then. Se revela al seguir unos principios clave que a menudo se pasan por alto. Este artículo desvela cinco de las prácticas más impactantes que transformarán tu estrategia de pruebas, convirtiéndola en una herramienta robusta, colaborativa y sostenible.
1. Tu escenario no es un script, es una historia (con un solo argumento)
El principio fundamental de un buen escenario Gherkin es que debe contar una historia coherente sobre un comportamiento específico del sistema, no ser una lista de pasos técnicos. Para lograrlo, es crucial respetar la estructura narrativa.
La secuencia de los pasos debe seguir un orden lógico estricto: Given -> When -> Then. El Given establece el contexto, el When describe la acción principal y el Then verifica el resultado. Nunca se debe colocar un When después de un Then, ya que esto rompe el flujo conceptual. Sería como realizar una nueva acción después de haber verificado la conclusión de la historia, lo cual es confuso y va en contra del propósito de BDD.
Además, cada escenario debe adherirse a la regla de «un flujo por escenario». Esto significa que no se deben repetir bloques Given-When-Then dentro del mismo escenario. Si sientes la necesidad de escribir una secuencia como When... Then... When... Then..., es una señal clara de que estás probando más de un comportamiento. La mejor práctica es dividirlo en múltiples escenarios independientes. Cada escenario debe representar una única unidad de comportamiento para mantenerlo enfocado, legible y fácil de mantener.
Ahora bien, aunque la regla de oro es «un flujo por escenario», en la práctica arquitectónica nos encontramos con casos excepcionales. Algunos equipos utilizan pragmáticamente múltiples bloques When-Then para flujos de auditoría de extremo a extremo muy largos, donde se busca validar una secuencia completa. Sin embargo, estos casos deben manejarse con cautela, ya que pueden comprometer la legibilidad y el mantenimiento. La recomendación principal sigue siendo aislar cada comportamiento importante en su propio escenario.
2. Enfócate en el «qué», no en el «cómo»
Uno de los errores más comunes al escribir escenarios es describir los detalles de la implementación en lugar de la intención del usuario. El principio de abstracción es clave para evitar pruebas frágiles y poco legibles.
Los pasos deben centrarse en la acción desde la perspectiva del negocio o del usuario, no en los detalles técnicos de la interfaz. Por ejemplo, es mucho más efectivo escribir "When intento iniciar sesión" que "When presiono el botón 'Login'". El primer enfoque describe la intención, mientras que el segundo está acoplado a un detalle específico de la interfaz de usuario (UI).
Los beneficios de este enfoque son dobles. Primero, el escenario se vuelve instantáneamente más comprensible para los interesados no técnicos, como los analistas de negocio o los gerentes de producto, fomentando una mejor colaboración. Segundo, la prueba se vuelve significativamente más robusta. Si el equipo de desarrollo cambia el botón por un enlace o modifica su identificador, el escenario centrado en el «qué» no necesita cambiar; solo se actualiza el código subyacente. El escenario centrado en el «cómo», en cambio, se rompería.
Los pasos del escenario deben centrarse en qué hace el usuario o qué ocurre, no en cómo se implementa.
3. Tus pruebas son tu mejor documentación (y siempre está actualizada)
El concepto de «documentación viva» es uno de los beneficios más poderosos de adoptar BDD correctamente. Cuando los escenarios se escriben con claridad y se centran en el comportamiento del negocio, se convierten en algo más que simples pruebas.
Estos escenarios, redactados en lenguaje natural, actúan como una especificación precisa y clara del comportamiento esperado del sistema. Describen cómo debe funcionar la aplicación desde la perspectiva del usuario, sirviendo como una fuente única de verdad para todo el equipo.
La parte más valiosa es que esta documentación nunca se vuelve obsoleta. Debido a que los escenarios son pruebas ejecutables que se validan continuamente contra el código de la aplicación, existe la garantía de que siempre estarán sincronizados con la funcionalidad real del sistema. Esto resuelve el problema crónico de la documentación tradicional, que a menudo queda desactualizada casi tan pronto como se escribe.
Un beneficio clave de BDD es que los escenarios sirven como documentación viva.
4. Separa las capas: La clave para un mantenimiento sin dolor
Para construir una suite de pruebas automatizadas que sea sostenible a largo plazo, es fundamental adoptar una arquitectura que separe claramente las responsabilidades. Una buena estructura BDD divide el trabajo en tres capas distintas, cada una con un propósito claro.
- Features/Escenarios (.feature files): Esta es la capa del «qué». Contiene las especificaciones de comportamiento escritas en Gherkin, en un lenguaje natural que todos en el equipo pueden entender. Define la intención de la prueba y los criterios de aceptación.
- Step Definitions (Código Python): Esta es la capa del «pegamento» (glue), una fina capa de orquestación. Su única responsabilidad es conectar los pasos en lenguaje natural con la lógica técnica. Las definiciones de pasos deben ser concisas y delegar toda la lógica pesada al código de soporte. No deben contener detalles de implementación, solo llamadas a métodos más complejos.
- Código de Soporte (Page Objects, utils): Esta es la capa del «cómo». Contiene la implementación técnica detallada que interactúa con la aplicación. Aquí residen patrones como los Page Objects, que encapsulan los localizadores de elementos de la UI y las acciones del navegador, o las funciones para interactuar con una API.
Esta separación es invaluable para el mantenimiento. Por ejemplo, si un selector de un elemento de la interfaz de usuario cambia, solo necesitas actualizar la clase Page Object correspondiente. Tanto el escenario Gherkin como la definición del paso (step definition) permanecen completamente intactos, aislando el impacto del cambio y haciendo que la suite de pruebas sea mucho más fácil de mantener.
5. Cada escenario es una isla: La regla de la independencia
Un principio no negociable para una suite de pruebas robusta y fiable es que cada escenario debe ser completamente independiente.
Cada escenario debe ser autocontenido, lo que significa que no puede depender del estado, los datos o los resultados dejados por un escenario que se ejecutó previamente. Acoplar escenarios, donde el éxito de uno depende de que otro se haya ejecutado antes, es una receta para el desastre.
Las consecuencias de los escenarios dependientes son graves: generan «fallos en cascada», donde un solo fallo inicial provoca que muchos otros fallen, haciendo casi imposible diagnosticar la causa raíz. Además, impiden la ejecución de pruebas en paralelo, una técnica crucial para obtener retroalimentación rápida en los ciclos de desarrollo modernos.
Para lograr esta independencia, cada escenario debe ser responsable de configurar su propio contexto y precondiciones en los pasos Given. Si varias precondiciones son verdaderamente comunes a todos los escenarios de un mismo archivo de características, se pueden agrupar en una sección Background. Sin embargo, una consideración estratégica es usar Background con moderación. Debe ser breve y contener únicamente los pasos esenciales, para que cada escenario individual siga siendo comprensible por sí solo sin requerir un contexto oculto.
Cada escenario debe ser idealmente autocontenido e independiente de los demás.
Adoptar estos cinco principios no se trata de seguir reglas arbitrarias, sino de abrazar una filosofía para crear suites de pruebas que sean robustas, mantenibles y, sobre todo, una herramienta de colaboración para todo el equipo. No solo validan el software, sino que también construyen un entendimiento compartido de lo que el sistema debe hacer.
Si revisaras tus pruebas actuales, ¿cuántas de ellas son historias claras y cuántas son scripts frágiles? ¿Qué pequeño cambio podrías hacer hoy para que sirvan mejor como documentación viva para tu equipo?