El behavior-driven development en el desarrollo ágil de software

Hace algunos años, comprobar la funcionalidad del producto final de un software era una tarea que podía tener ocupado a un departamento de calidad durante semanas. Hoy en día, sin embargo, gracias a los test automáticos, bastan unos pocos clics para averiguar si una compleja aplicación cumple su función o no. En este sentido, el behavior-driven development (BDD), o desarrollo guiado por comportamiento, es una técnica cada vez más popular. Se trata de una forma de desarrollo ágil de software que surgió a partir del desarrollo guiado por pruebas o test-driven development (TDD) y que se considera como una extensión lógica del mismo. A diferencia de lo que ocurre en el TDD, en el BDD, el software en cuestión se analiza desde la perspectiva del usuario, un planteamiento que favorece un diseño más holístico y que facilita el trabajo conjunto de desarrolladores, gestores de calidad y clientes.

¿Qué es el behavior-driven development?

A medida que aumenta la complejidad de las aplicaciones de software, van apareciendo nuevos métodos de gestión de pruebas y de evaluación de la calidad. Estos procedimientos son indispensables para asegurar que el software funciona de forma fiable e identificar fallos desde el primer momento. Una de estas técnicas, ya extendida desde hace un tiempo, es el desarrollo guiado por pruebas o test-driven development (TDD), con el que los desarrolladores crean, de forma paralela al software en sí, los test de unidad o de sistema correspondientes. Sin embargo, en el diseño de software, conviene involucrar también a otros miembros del equipo o personas interesadas, quienes no necesariamente tienen conocimientos en materia de códigos de programación. El behavior-driven development (BDD) o desarrollo guiado por comportamiento soluciona precisamente este problema.

El desarrollo ágil de software permite que todos los participantes de un proyecto determinen las características que desean ver en una aplicación antes de que el programador empiece a redactar el código fuente. Estas especificaciones se expresan en un lenguaje fácil de comprender, de manera que incluso el cliente para el que se realiza el software puede participar activamente en su diseño. De este modo, el BDD promueve el trabajo conjunto entre las distintas áreas del proyecto y el reparto de la responsabilidad. Si se aplica de forma adecuada desde el inicio, esta forma de desarrollo ágil de software evita malentendidos y da como resultado, en el mejor de los casos, un producto de gran calidad.

¿Cómo funciona exactamente el behavior-driven development?

Como puede intuirse por su propio nombre, el behavior-driven development se guía por el comportamiento que desea obtenerse del software final. Gracias al llamado lenguaje ubicuo, una especie de lenguaje común, incluso los no expertos pueden describir comportamientos específicos. El lenguaje ubicuo nació en el ámbito del domain-driven design (DDD, diseño guiado por el dominio), una metodología que, al igual que el BDD, se centra en los ámbitos de aplicación del producto. Ambos planteamientos tienen en cuenta todas las áreas involucradas en el proyecto de software y las interconectan más allá de los frameworks, los lenguajes de programación o las herramientas concretas, todo gracias al lenguaje ubicuo o común.

No obstante, el behavior-driven development no puede prescindir totalmente de las herramientas y los marcos de trabajo: hay que respetar ciertas reglas para que los casos de prueba que se definan puedan traducirse a un lenguaje de programación ejecutable. Por este motivo, las especificaciones en BDD no se expresan en forma de texto corrido, sino que, con ayuda de herramientas BDD como JBehave, Cucumber o Behat, se ajustan a una estructura determinada que hace posible su correcta implementación. Sin embargo, manejar estas herramientas es mucho más fácil que aprender un lenguaje de programación convencional. A continuación, te explicamos la estructura que normalmente se sigue en el desarrollo guiado por comportamiento:

  • Primero, se realiza un análisis de requisitos en el que se especifican las tareas, los objetivos y las funciones del software. En esta fase, la empresa se pregunta (o pregunta a los clientes) qué debe ser capaz de hacer el software.
  • Una vez se han identificado todas las funciones, estas se describen en forma de escenarios predefinidos: el objetivo es pensar en todas las situaciones posibles en las que el software debería reaccionar dando una respuesta concreta.
  • El siguiente paso es establecer la respuesta que se espera en cada escenario o situación mediante un esquema tipo given-when-then, es decir, dado-cuando-entonces: dado describe el estado del software antes del test; cuando describe la acción durante el test y entonces describe el estado del software tras el test.

Según qué herramienta de BDD se utilice, el vocabulario usado puede variar ligeramente. Estas herramientas están disponibles para los lenguajes de programación más comunes, como Java, JavaScript, Python o Ruby.

Desarrollo guiado por comportamiento: un ejemplo práctico

Imagina que quieres desarrollar una tienda online intuitiva que guarde los datos de usuario de cada cliente que se registre: así, los clientes pueden simplemente iniciar sesión y evitar tener que volver a introducir sus datos personales. En Gherkin, un lenguaje de programación muy extendido y que se usa en la herramienta de BDD Cucumber, la sintaxis correspondiente tendría la siguiente forma:

Funcionalidad: un cliente ya registrado quiere iniciar sesión en su cuenta de usuario.
	Escenario: el cliente introduce correctamente sus datos de acceso a la cuenta.
		Dado que tengo una cuenta de usuario activa
		Y me encuentro en la página de inicio
		Cuando teclee mi dirección de correo electrónico en el campo correspondiente
		Y teclee la contraseña asociada en el campo correspondiente
		Y haga clic en la tecla de iniciar sesión
		Entonces debería iniciarse mi sesión

El ejemplo anterior muestra que pueden añadirse diversas condiciones usando el elemento Y, lo cual permite crear casos de prueba más complejos.

¿Qué diferencia al BDD de otros métodos de prueba?

Al poner a prueba un software, el desarrollo guiado por comportamiento se guía sobre todo por la pregunta cómo: las partes implicadas quieren saber cómo comprobar el comportamiento de un código, no su implementación. En los llamados test de módulos, en cambio, se trata de comprobar si una unidad de código concreta está siendo implementada de forma correcta. Estos procedimientos de prueba permiten detectar bugs rápidamente, por lo que se basan en la pregunta qué. Por otra parte, la pregunta del ¿y si…? obtiene su respuesta gracias al test-driven development, que pone a prueba el proceso de ejecución de los test, el cual puede incluir también test de módulos u otro tipo de pruebas.

Nota

Además de los test de módulos, también existen test funcionales y de integración, que son bastante más complejos puesto que analizan la interacción entre distintas partes del sistema y la funcionalidad del conjunto del software.

La siguiente tabla resume las ventajas y los inconvenientes del behavior-driven development:

Ventajas Inconvenientes
Ideal para principiantes gracias al lenguaje ubicuo, que no requiere conocimientos previos. Las especificaciones mal redactadas dificultan el trabajo de los desarrolladores.
Mejor comunicación entre desarrolladores, stakeholders y gestores de la calidad. Como integra a diversas partes interesadas, el proceso de desarrollo se alarga.
Los casos de prueba son una documentación viviente que puede adaptarse fácilmente. La conversión a un flujo de trabajo BDD supone un esfuerzo añadido si se usan códigos heredados.
La prioridad es el confort del usuario al manejar el software.  

Si bien se pueden aplicar los diferentes métodos de prueba uno a uno, la calidad del software mejora considerablemente si se utiliza una combinación de varios. El BDD ayuda a identificar el mejor enfoque para escribir test, mientras que el TDD se encarga de conseguir una alta cobertura en las pruebas.

¿Le ha resultado útil este artículo?