Desarrollo guiado por comportamiento (BDD)

El desarrollo guiado por comportamiento (BDD, Behavior-Driven Development) es una forma de construir un entendimiento compartido antes de escribir el código. Producto, desarrollo y testing (los llamados “three amigos”) discuten una funcionalidad a través de ejemplos concretos de cómo debe comportarse. Esos ejemplos se convierten en los criterios de aceptación, y muchos equipos los automatizan después como especificaciones ejecutables con herramientas como Cucumber, Reqnroll (el sucesor de SpecFlow) o Behave.

Ejemplo

Una conversación sobre una regla de descuento se transforma en ejemplos como estos:

Feature: Loyalty discount

  Scenario: Gold members get 10% off orders over 100
    Given a customer with Gold membership
    When they check out a basket worth 120.00
    Then the order total is 108.00

  Scenario: The discount does not apply at exactly 100
    Given a customer with Gold membership
    When they check out a basket worth 100.00
    Then the order total is 100.00

El segundo escenario es el valioso. Escribirlo obliga a plantear la pregunta “¿más de 100, o 100 o más?” antes de que alguien construya lo que no es.

Las tres prácticas

1. Descubrimiento. Explorar la funcionalidad con ejemplos, encontrar casos límite y preguntas abiertas.
2. Formulación. Escribir los ejemplos acordados en una forma estructurada y legible para negocio, normalmente Gherkin.
3. Automatización. Vincular cada paso a código para que los ejemplos se ejecuten como pruebas y sirvan de documentación viva.

Errores comunes

• Tratar BDD como una herramienta de testing. Escribir Gherkin después del código, en solitario y sin conversación, te da el coste de una capa de traducción sin el beneficio del entendimiento compartido.
• Pasos a nivel de UI. “When I click the button with id submit” describe la interfaz, no el comportamiento. Los pasos deberían sobrevivir a un rediseño.
• Automatizar todos los escenarios a través del navegador. Una regla de negocio como el descuento anterior suele ser más rápida y fiable de automatizar contra una API o la capa de servicios.
• Bibliotecas de pasos enormes. Cientos de definiciones de pasos ligeramente distintas son difíciles de mantener. Mantén un vocabulario pequeño y centrado en el dominio.

BDD funciona bien cuando la gente de negocio realmente lee los escenarios y contribuye a ellos. Cuando nadie fuera de ingeniería los mira, un código de pruebas normal con buenos nombres suele ser más sencillo.