Hace algunos años, comprobar la fu­n­cio­na­li­dad del producto final de un software era una tarea que podía tener ocupado a un de­pa­r­ta­me­n­to de calidad durante semanas. Hoy en día, sin embargo, gracias a los test au­to­má­ti­cos, bastan unos pocos clics para averiguar si una compleja apli­ca­ción cumple su función o no. En este sentido, el behavior-driven de­ve­lo­p­me­nt (BDD), o de­sa­rro­llo guiado por co­m­po­r­ta­mie­n­to, es una técnica cada vez más popular. Se trata de una forma de de­sa­rro­llo ágil de software que surgió a partir del de­sa­rro­llo guiado por pruebas o test-driven de­ve­lo­p­me­nt (TDD) y que se considera como una extensión lógica del mismo. A di­fe­re­n­cia de lo que ocurre en el TDD, en el BDD, el software en cuestión se analiza desde la pe­r­s­pe­c­ti­va del usuario, un pla­n­tea­mie­n­to que favorece un diseño más holístico y que facilita el trabajo conjunto de de­sa­rro­lla­do­res, gestores de calidad y clientes.

¿Qué es el behavior-driven de­ve­lo­p­me­nt?

A medida que aumenta la co­m­ple­ji­dad de las apli­ca­cio­nes de software, van apa­re­cie­n­do nuevos métodos de gestión de pruebas y de eva­lua­ción de la calidad. Estos pro­ce­di­mie­n­tos son in­di­s­pe­n­sa­bles para asegurar que el software funciona de forma fiable e ide­n­ti­fi­car fallos desde el primer momento. Una de estas técnicas, ya extendida desde hace un tiempo, es el de­sa­rro­llo guiado por pruebas o test-driven de­ve­lo­p­me­nt (TDD), con el que los de­sa­rro­lla­do­res crean, de forma paralela al software en sí, los test de unidad o de sistema co­rre­s­po­n­die­n­tes. Sin embargo, en el diseño de software, conviene in­vo­lu­crar también a otros miembros del equipo o personas in­te­re­sa­das, quienes no ne­ce­sa­ria­me­n­te tienen co­no­ci­mie­n­tos en materia de códigos de pro­gra­ma­ción. El behavior-driven de­ve­lo­p­me­nt (BDD) o de­sa­rro­llo guiado por co­m­po­r­ta­mie­n­to soluciona pre­ci­sa­me­n­te este problema.

El de­sa­rro­llo ágil de software permite que todos los pa­r­ti­ci­pa­n­tes de un proyecto de­te­r­mi­nen las ca­ra­c­te­rí­s­ti­cas que desean ver en una apli­ca­ción antes de que el pro­gra­ma­dor empiece a redactar el código fuente. Estas es­pe­ci­fi­ca­cio­nes se expresan en un lenguaje fácil de co­m­pre­n­der, de manera que incluso el cliente para el que se realiza el software puede pa­r­ti­ci­par ac­ti­va­me­n­te en su diseño. De este modo, el BDD promueve el trabajo conjunto entre las distintas áreas del proyecto y el reparto de la re­s­po­n­sa­bi­li­dad. Si se aplica de forma adecuada desde el inicio, esta forma de de­sa­rro­llo ágil de software evita ma­le­n­te­n­di­dos y da como resultado, en el mejor de los casos, un producto de gran calidad.

¿Cómo funciona exac­ta­me­n­te el behavior-driven de­ve­lo­p­me­nt?

Como puede intuirse por su propio nombre, el behavior-driven de­ve­lo­p­me­nt se guía por el co­m­po­r­ta­mie­n­to que desea obtenerse del software final. Gracias al llamado lenguaje ubicuo, una especie de lenguaje común, incluso los no expertos pueden describir co­m­po­r­ta­mie­n­tos es­pe­cí­fi­cos. El lenguaje ubicuo nació en el ámbito del domain-driven design (DDD, diseño guiado por el dominio), una me­to­do­lo­gía que, al igual que el BDD, se centra en los ámbitos de apli­ca­ción del producto. Ambos pla­n­tea­mie­n­tos tienen en cuenta todas las áreas in­vo­lu­cra­das en el proyecto de software y las in­te­r­co­ne­c­tan más allá de los fra­me­wo­r­ks, los lenguajes de pro­gra­ma­ción o las he­rra­mie­n­tas concretas, todo gracias al lenguaje ubicuo o común.

No obstante, el behavior-driven de­ve­lo­p­me­nt no puede pre­s­ci­n­dir to­ta­l­me­n­te de las he­rra­mie­n­tas y los marcos de trabajo: hay que respetar ciertas reglas para que los casos de prueba que se definan puedan tra­du­ci­r­se a un lenguaje de pro­gra­ma­ción eje­cu­ta­ble. Por este motivo, las es­pe­ci­fi­ca­cio­nes en BDD no se expresan en forma de texto corrido, sino que, con ayuda de he­rra­mie­n­tas BDD como JBehave, Cucumber o Behat, se ajustan a una es­tru­c­tu­ra de­te­r­mi­na­da que hace posible su correcta im­ple­me­n­ta­ción. Sin embargo, manejar estas he­rra­mie­n­tas es mucho más fácil que aprender un lenguaje de pro­gra­ma­ción co­n­ve­n­cio­nal. A co­n­ti­nua­ción, te ex­pli­ca­mos la es­tru­c­tu­ra que no­r­ma­l­me­n­te se sigue en el de­sa­rro­llo guiado por co­m­po­r­ta­mie­n­to:

  • Primero, se realiza un análisis de re­qui­si­tos en el que se es­pe­ci­fi­can 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 ide­n­ti­fi­ca­do todas las funciones, estas se describen en forma de es­ce­na­rios pre­de­fi­ni­dos: el objetivo es pensar en todas las si­tua­cio­nes posibles en las que el software debería reac­cio­nar dando una respuesta concreta.
  • El siguiente paso es es­ta­ble­cer 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é he­rra­mie­n­ta de BDD se utilice, el vo­ca­bu­la­rio usado puede variar li­ge­ra­me­n­te. Estas he­rra­mie­n­tas están di­s­po­ni­bles para los lenguajes de pro­gra­ma­ción más comunes, como Java, Ja­va­S­cri­pt, Python o Ruby.

De­sa­rro­llo guiado por co­m­po­r­ta­mie­n­to: un ejemplo práctico

Imagina que quieres de­sa­rro­llar una tienda online intuitiva que guarde los datos de usuario de cada cliente que se registre: así, los clientes pueden si­m­ple­me­n­te iniciar sesión y evitar tener que volver a in­tro­du­cir sus datos pe­r­so­na­les. En Gherkin, un lenguaje de pro­gra­ma­ción muy extendido y que se usa en la he­rra­mie­n­ta de BDD Cucumber, la sintaxis co­rre­s­po­n­die­n­te 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 co­n­di­cio­nes usando el elemento Y, lo cual permite crear casos de prueba más complejos.

¿Qué di­fe­re­n­cia al BDD de otros métodos de prueba?

Al poner a prueba un software, el de­sa­rro­llo guiado por co­m­po­r­ta­mie­n­to se guía sobre todo por la pregunta cómo: las partes im­pli­ca­das quieren saber cómo comprobar el co­m­po­r­ta­mie­n­to de un código, no su im­ple­me­n­ta­ción. En los llamados test de módulos, en cambio, se trata de comprobar si una unidad de código concreta está siendo im­ple­me­n­ta­da de forma correcta. Estos pro­ce­di­mie­n­tos de prueba permiten detectar bugs rá­pi­da­me­n­te, por lo que se basan en la pregunta qué. Por otra parte, la pregunta del ¿y si…? obtiene su respuesta gracias al test-driven de­ve­lo­p­me­nt, 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 fu­n­cio­na­les y de in­te­gra­ción, que son bastante más complejos puesto que analizan la in­ter­ac­ción entre distintas partes del sistema y la fu­n­cio­na­li­dad del conjunto del software.

La siguiente tabla resume las ventajas y los in­co­n­ve­nie­n­tes del behavior-driven de­ve­lo­p­me­nt:

Ventajas In­co­n­ve­nie­n­tes
Ideal para pri­n­ci­pia­n­tes gracias al lenguaje ubicuo, que no requiere co­no­ci­mie­n­tos previos. Las es­pe­ci­fi­ca­cio­nes mal re­da­c­ta­das di­fi­cu­l­tan el trabajo de los de­sa­rro­lla­do­res.
Mejor co­mu­ni­ca­ción entre de­sa­rro­lla­do­res, sta­keho­l­de­rs y gestores de la calidad. Como integra a diversas partes in­te­re­sa­das, el proceso de de­sa­rro­llo se alarga.
Los casos de prueba son una do­cu­me­n­ta­ción viviente que puede adaptarse fá­ci­l­me­n­te. La co­n­ve­r­sió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 di­fe­re­n­tes métodos de prueba uno a uno, la calidad del software mejora co­n­si­de­ra­ble­me­n­te si se utiliza una co­m­bi­na­ción de varios. El BDD ayuda a ide­n­ti­fi­car el mejor enfoque para escribir test, mientras que el TDD se encarga de conseguir una alta cobertura en las pruebas.

Ir al menú principal