BDD Testing. Acercando negocio y desarrollo

¿Qué es el BDD?

El BDD (Behaviour Driven Development), es una metodología que enfoca el desarrollo de software desde la perspectiva del usuario final. Se trata de entender las necesidades del cliente, poniéndonos en sus zapatos, y diseñar el software para que se comporte adecuadamente en diversas situaciones, asegurando su satisfacción.

En una empresa de desarrollo de software, donde la innovación y la calidad son indispensables para destacar, el BDD ha ido ganando popularidad desde su introducción en 2006 y está transformando la manera en que creamos aplicaciones.

Si alguna vez te has preguntado cómo garantizar una comunicación fluida entre equipos de desarrollo y stakeholders, o cómo asegurarte de que cada funcionalidad entregada aporte un valor real al usuario final, cumpliendo los criterios de aceptación (o UAT) entonces esta perspectiva te sorprenderá.

No se trata solo de una metodología más, sino de una filosofía de qa testing que pone el enfoque en el usuario, la calidad y la colaboración.

¿Cómo funciona BDD?

El BDD pone una capa de lenguaje natural por encima del código.

Es un DSL (Domain Specific Language) que simplifica usar código (java, ruby, javascript...) poniendo a Gherkin por encima.

Algunas de sus características principales, son:

Colaboración entre equipos: BDD promueve la colaboración entre los equipos de desarrollo, negocio y calidad. Todos los miembros del equipo trabajan juntos para identificar los comportamientos clave del sistema y definirlos en un lenguaje común comprensible por todos.

Especificaciones en lenguaje natural: Una característica clave de BDD es la expresión de los requisitos y comportamientos de forma fácil, evitando jerga técnica. El lenguaje empleado es Gherkin, un “lenguaje específico de dominio” (o DSL, según sus iniciales en inglés, Domain Specific Language), tan sencillo como sus términos Given, When, Then. Esto facilita la comprensión tanto para los no técnicos como para los desarrolladores, lo que lleva a una mayor alineación entre equipos.

Automatización de pruebas: Mediante el uso de herramientas de automatización, los comportamientos definidos en lenguaje natural se traducen en escenarios de pruebas funcionales o no funcionales, ejecutables. Esto garantiza que el software cumpla con los requisitos establecidos y se comporta como se espera, evitando regresiones y errores.

Para implementar eficazmente BDD y aprovechar al máximo sus beneficios, es importante tener una **guía de buenas prácticas con Gherkin y Cucumber**. Gherkin para expresar las especificaciones en lenguaje natural, y Cucumber para automatizar las pruebas. Estas son las herramientas más populares en la metodología BDD.

BDD: Ejemplo de uso

Supongamos que estamos desarrollando un ecommerce y queremos probar el proceso de agregar un artículo al carrito.

Lo primero crea un archivo agregar_al_carrito.feature en la raíz del proyecto con el siguiente contenido escrito en Gherkin (¡que admite decenas de idiomas!):

Característica: Agregar artículo al carrito
Como cliente    
Quiero poder agregar artículos al carrito    
Para poder realizar una compra en línea


Escenario: Agregar artículo al carrito exitosamente   
Dado que estoy en la página de un artículo    
Cuando agrego el artículo al carrito    
Entonces debería ver un mensaje de confirmación
Y el carrito debería mostrar el artículo agregado

Ahora, traduciremos este escenario en código ejecutable utilizando Cucumber en lenguaje JavaScript, creando un archivo agregar_al_carrito_steps.js con el siguiente contenido:

const { Given, When, Then } = require('cucumber');

Given("que estoy en la página de un artículo", function () {
// Código para navegar a la página del artículo
});

When('agrego el artículo al carrito', function () {
// Código para agregar un artículo al carrito
});

Then("debería ver un mensaje de confirmación", function () {
// Código para verificar que se muestra el mensaje de confirmación
});

Then("el carrito debería mostrar el artículo agregado", function () {
// Código para verificar que el artículo se muestra en el carrito
});

Y de esta forma podremos crear pruebas automatizadas basadas en escenarios escritos en lenguaje natural. Esto permite una comunicación efectiva entre el equipo no técnico y los desarrolladores, mejorando la colaboración y la comprensión de las pruebas.

¿Por qué debería utilizar BDD en mi proyecto?

Mayor comprensión de los requisitos: Con BDD, todos los miembros del equipo tienen una visión clara y compartida de lo que se espera del software. Esto minimiza la posibilidad de malentendidos (principalmente entre Producto y Programadores), a la vez que se reduce el riesgo de desarrollar características innecesarias o no desarrollar las requeridas.

Enfoque en el valor del usuario: BDD se centra en el valor que el software aporta al usuario final. Al definir los comportamientos desde la perspectiva del cliente, se garantiza que el desarrollo esté alineado con las necesidades reales.

Reducción de errores y costes: La automatización de pruebas en BDD ayuda a detectar errores en etapas tempranas del desarrollo, lo que reduce el coste de corregir problemas más adelante en el proceso.

¿En qué se diferencian BDD y TDD? (Desarrollo Dirigido por Pruebas)

Ambas metodologías son enfoques populares para mejorar la calidad y la eficiencia del desarrollo de software, pero tienen enfoques distintos para lograr sus objetivos.

Similitudes entre BDD y TDD:

Pruebas automatizadas: BDD y TDD son metodologías basadas en la ejecución de pruebas de manera automática. En ambos enfoques, las pruebas son escritas antes o simultáneamente a la implementación del código y se ejecutan automáticamente para verificar el comportamiento del software.

Orientación a la calidad: Tanto BDD como TDD tienen como fin mejorar la calidad del software mediante la detección temprana de errores y la garantía de que el código se ajusta a los requisitos definidos.

Enfoque incremental: Ambas validan pequeñas unidades de funcionalidad y pueden integrarse en el ciclo de desarrollo del proyecto.

TDD vs BDD:

Enfoque de las pruebas: La principal diferencia entre BDD y TDD radica en el enfoque de las pruebas. Mientras que TDD se centra en pruebas unitarias a nivel de código para validar el comportamiento de las funciones o métodos, BDD se enfoca en pruebas funcionales a nivel de la aplicación, expresadas en lenguaje natural, desde la perspectiva del usuario final.

Comunicación y Lenguaje: BDD promueve una comunicación más efectiva entre los miembros del equipo y los interesados mediante la expresión de requisitos y funcionalidades en lenguaje natural. Por otro lado, TDD utiliza lenguaje técnico y se enfoca en pruebas más específicas y atómicas de funciones, a nivel de código.

Interesados e involucrados: BDD implica directamente a los interesados en el proyecto, desde el equipo técnico a los stakeholders, en la definición de funcionalidades. TDD, en cambio, es un recurso de uso casi exclusivo del equipo de desarrollo.

Velocidad de ejecución: Una batería test unitarios programados empleando TDD pueden (y deberían) tardar sólo unas décimas de segundo en ejecutarse. Los test desarrollados bajo BDD, por el contrario, son más laboriosos de programar, suelen tardar varios minutos aún ejecutándose en paralelo y si no están programados de manera resiliente, son bastante más frágiles. Por si dudas, en este post te contamos cómo saber si tus tests de software son buenos.

¿Pueden combinarse BDD y TDD?

¡Por supuesto! BDD y TDD no sólo pueden complementarse en el proceso de desarrollo de software, sino que te lo recomendamos encarecidamente. Muchos equipos encuentran que ambos enfoques se complementan mutuamente.

BDD proporciona una visión clara de la funcionalidad del software desde el punto de vista del usuario, lo que ayuda a asegurarse de que el desarrollo se alinee con las necesidades reales. A su vez, TDD se enfoca en la validación del comportamiento a nivel de código, lo que garantiza la calidad y robustez de las funcionalidades individuales.

Al usar ambos enfoques, los equipos pueden obtener una cobertura más amplia en la validación del software, asegurando tanto la funcionalidad general como la calidad de las unidades individuales de código.

Si te gustaría descubrir qué es TDD, con ejemplos para que lo pongas en práctica desde hoy en tu proyecto, corre a leer el post **TDD: Escribiendo pruebas primero, para un desarrollo sin miedo**

BDD es para ti

Si aún no has probado BDD en tus proyectos, te animo a que lo explores y descubras el poder que puede aportar a tu equipo y tus aplicaciones. ¡Adoptarlo podría ser el impulso que necesitas para llevar tu desarrollo al siguiente nivel!

En Redsauce, centramos el desarrollo en aportar valor para el usuario final y aseguramos que cada funcionalidad, test o línea de código contribuya positivamente a su experiencia.

Esta y otras 30 metodologías y consejos están explicadas en detalle en nuestro ebook gratuito. Comienza ahora a mejorar tu desarrollo: