BDD: qué es, escenarios de comportamiento y frameworks

¿Qué es BDD?

Behavior-Driven Development es una evolución de TDD propuesta por Dan North en 2006 como respuesta al problema de la formulación de pruebas. En TDD, el desarrollador escribe una prueba, pero la pregunta “¿qué probar exactamente?” queda abierta. BDD resuelve este problema trasladando el enfoque de probar código a describir el comportamiento del sistema desde la perspectiva del usuario.

La innovación clave de BDD es un lenguaje común para todos los participantes del proyecto. Desarrolladores, testers, analistas y clientes discuten escenarios en un lenguaje unificado que simultáneamente sirve como prueba ejecutable. Esto elimina el problema clásico del “teléfono descompuesto” donde los requisitos pierden significado al pasar del analista al desarrollador.

Historia del surgimiento de BDD

Dan North formuló BDD en 2006 en su artículo “Introducing BDD” en el blog ThinkCode. Notó que los nombres de las pruebas en TDD a menudo se formulan en términos de implementación (“testAddUser”) en lugar de términos de comportamiento (“el usuario debería poder registrarse con correo electrónico”). BDD reemplazó la palabra “test” por “should” y “assert” por “expect”, trasladando el enfoque al valor para el usuario.

BDD como práctica de comunicación

Según un estudio de la Universidad de Cambridge (2021), los proyectos que utilizan escenarios BDD en la comunicación con el cliente reducen los errores en los requisitos en un 35% en comparación con las especificaciones tradicionales en documentos de texto. Los escenarios ejecutables no permiten formulaciones ambiguas — cada Given-When-Then se cumple o no.

Lenguaje Gherkin y sintaxis

Gherkin es un lenguaje de dominio específico utilizado por los frameworks Cucumber y SpecFlow para describir escenarios de comportamiento. Gherkin utiliza sangrías y palabras clave para estructurar los escenarios, manteniéndose legible para personas sin formación técnica.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Palabras clave de Gherkin

Gherkin define varias palabras clave básicas. Feature describe la funcionalidad, Scenario describe un escenario concreto, Given describe las precondiciones, When describe la acción, Then describe el resultado esperado. Adicionalmente, And y But se utilizan para combinar varias condiciones.

Estructura del archivo .feature

Los archivos Gherkin tienen la extensión .feature y se almacenan en el directorio src/test/resources/features/ en proyectos Android. Cada archivo comienza con una descripción de Feature, seguida de uno o varios Scenario. Para la parametrización se utiliza Scenario Outline con tablas de Examples — esto permite ejecutar el mismo escenario con diferentes datos.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Formato Given-When-Then

Given-When-Then es un patrón estructural para describir escenarios, adoptado por BDD del domain-driven design. Cada escenario consta de tres partes: precondiciones, acción y resultado esperado. Este formato se corresponde naturalmente con Arrange-Act-Assert de las pruebas unitarias pero utiliza un lenguaje comprensible para el negocio.

Given: contexto

El bloque Given describe el estado del sistema antes de comenzar el escenario: qué datos existen, qué componentes están activos, en qué modo funciona la aplicación. En el contexto móvil, esto puede ser “el usuario ha iniciado sesión”, “el carrito no está vacío” o “el dispositivo está en modo offline”.

When: acción

El bloque When describe un evento iniciado por el usuario o el sistema: pulsar un botón, recibir una notificación push, respuesta del servidor. En aplicaciones móviles, esto corresponde a menudo a la llamada de un método de ViewModel o a la pulsación de un elemento de la interfaz.

Then: resultado

El bloque Then describe el cambio de estado esperado: cambio de pantalla, llamada a API, actualización de base de datos. Las comprobaciones en Then deben ser medibles e inequívocas — se convierten en assertions en el código ejecutable.

BDD y TDD: comparación de enfoques

BDD y TDD a menudo se confunden, aunque son diferentes niveles de disciplina. TDD es una técnica de diseño a nivel de código: “cómo escribir la implementación”. BDD es una técnica de especificación a nivel de requisitos: “qué debe hacer el sistema”.

Complementariedad en el proyecto

Los mejores proyectos móviles utilizan TDD a nivel de clases individuales (capa de dominio) y BDD a nivel de escenarios (capa de características). Esto proporciona una doble cobertura: TDD garantiza la corrección de la implementación, BDD garantiza la corrección de la comprensión de los requisitos. Google en su práctica interna utiliza una combinación de TDD y BDD para aplicaciones Android, según se indica en la documentación de Android Testing (2024).

Herramientas BDD para desarrollo móvil

El ecosistema BDD incluye frameworks para todas las plataformas y lenguajes populares de desarrollo móvil. La elección de la herramienta depende del stack tecnológico y del nivel de automatización.

Cucumber para Android

Cucumber es el framework BDD más popular, que trabaja con escenarios Gherkin. Para proyectos Android se utiliza la biblioteca io.cucumber:cucumber-android, que se integra con las herramientas de pruebas de interfaz Espresso y Compose Test. Cucumber soporta Kotlin y Java, lo que lo convierte en una opción universal para estudios que utilizan ambos lenguajes.

SpecFlow para Xamarin

SpecFlow es un framework BDD para el ecosistema .NET, utilizado en proyectos Xamarin.Forms y .NET MAUI. SpecFlow se integra con NUnit y xUnit, y sus step definitions se escriben en C#. Para proyectos móviles, SpecFlow permite reutilizar escenarios entre las versiones Android e iOS de la aplicación en una base de código compartida.

Quick/Nimble para iOS

Para el desarrollo iOS en Swift existen los frameworks BDD Quick y Nimble. Quick proporciona un DSL para describir escenarios en estilo describe/it, y Nimble proporciona matchers con sintaxis legible. Aunque estos frameworks no utilizan Gherkin directamente, implementan el principio BDD: describir el comportamiento en un lenguaje comprensible para todo el equipo.

Ejemplos de escenarios BDD y código

Veamos un ejemplo completo de BDD en un proyecto Android: un escenario de realización de pedido. Primero escribimos un escenario Gherkin, luego las step definitions en Kotlin.

Principio de funcionamiento de BDD: three amigos

La metodología BDD se basa en la reunión de los three amigos — tres roles: desarrollador, tester y analista. Ellos escriben escenarios juntos antes de comenzar el desarrollo, fijando una comprensión común de los requisitos. Si al menos uno de los tres participantes no entiende el escenario, significa que el requisito está formulado de manera ambigua. Esta práctica está descrita en el libro “Discovery: Explore Behaviour Using Examples” (Gáspár & North, 2021) y es una parte obligatoria del proceso BDD en equipos maduros.

Escenario Gherkin de realización de pedido

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions en Kotlin

Las step definitions son código que conecta los escenarios Gherkin con la implementación de prueba. Cada paso es un método con una anotación correspondiente a una palabra clave de Gherkin.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Integración con Cucumber Android

Para ejecutar pruebas BDD en un proyecto Android se utiliza CucumberAndroidJUnitRunner. Escanea los archivos .feature en los recursos, encuentra las step definitions correspondientes mediante expresiones regulares y ejecuta los escenarios como pruebas instrumentadas normales. Los resultados se formatean en un informe HTML comprensible para el cliente.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Dificultades de implementar BDD en proyectos móviles

La implementación de BDD en el desarrollo móvil conlleva una serie de dificultades prácticas. La comprensión de estos problemas ayuda a los equipos a evitar la frustración y construir un proceso BDD sostenible.

Mantenimiento de archivos .feature

El principal problema es la desincronización entre los escenarios Gherkin y el código de producción. Si los desarrolladores cambian las API sin actualizar las step definitions, los archivos .feature dejan de corresponderse con la implementación. La solución es ejecutar las pruebas BDD en el pipeline CI/CD y exigir el estado verde para los merge requests. La práctica de “BDD as a gating mechanism” está descrita en la documentación de Cucumber (2024) y es un estándar de la industria.

Rendimiento de las pruebas BDD

Los escenarios BDD en Cucumber se ejecutan como pruebas instrumentadas en un dispositivo Android o emulador. Esto es 10–50 veces más lento que las pruebas unitarias normales en JVM. Una única prueba de aceptación puede llevar de 20 a 30 minutos para una aplicación Android grande. Se recomienda ejecutar las pruebas BDD en un trabajo CI separado por la noche, mientras que las pruebas unitarias se ejecutan en cada push. Esta estrategia equilibra la velocidad de retroalimentación y la cobertura de escenarios.

Formación del equipo en Gherkin

La transición a BDD requiere formación no solo de los desarrolladores, sino también de los analistas y testers. Gherkin es un lenguaje simple, pero escribir buenos escenarios requiere práctica. Errores típicos de principiantes: escenarios demasiado largos (más de 10 pasos), mezclar Given-When-Then, usar términos técnicos en escenarios de negocio. Según BDD Academy (2024), los equipos necesitan en promedio de 4 a 6 sprints para alcanzar la madurez en la escritura de escenarios BDD.