Qué es Behavior Driven Development (BDD)

4min

Behavior Driven Development (BDD), o desarrollo orientado al comportamiento, es una metodología agile de desarrollo software en la que una aplicación se documenta y diseña en función del comportamiento que los usuarios esperan experimentar al interactuar con ella.

Es decir, bajo el prisma BDD el software se analiza desde la perspectiva del usuario, y todo el diseño, el desarrollo, las pruebas y el producto final gira en torno a esa perspectiva y a lo que las personas esperan de este. Es, por decirlo así, un enfoque de desarrollo empático con el usuario.

Al tratar de centrarse sólo en los comportamientos solicitados, el BDD ayuda a evitar el exceso de código, las características innecesarias o la falta de foco. Esta metodología combina, aumenta y perfecciona las prácticas utilizadas en el TDD (Test Driven Development).

¿Cómo es el proyecto típico BDD? Esta metodología de desarrollo empieza con un diálogo entre los desarrolladores, los directivos y el cliente para entender cómo debe funcionar el producto. Tras realizar las pruebas de comportamiento pertinentes, el producto cumplirá con esos requisitos y estará en condiciones de ser entregado al cliente.

La ventaja diferencial de BDD es que ofrece la posibilidad de ampliar el conjunto de aportaciones y comentarios con tanto las partes interesadas de la empresa como los propios usuarios finales. Aunque estas personas tengan pocos o nulos conocimientos de desarrollo, su percepción en cuanto a las necesidades que cubrir permitirá que el proyecto evolucione en esa dirección, y no otra, y además será más sencillo incluir BDD en entornos de integración continua y entrega continua.

Índice

Given-When-Then, el lenguaje común del BDD

Given-When-Then (GWT) es un lenguaje semiestructurado que se utiliza para escribir casos de prueba. Establece tres estados o fases en las que se expone el contexto inicial de una prueba (given); una fase en la que se especifica qué acción se lleva a cabo; y la última fase en la que se especifica la consecuencia o consecuencias observables que deberían ocurrir.

Un ejemplo para entender mejor esto, adaptado de Agile Alliance:

  • GIVEN: mi cuenta bancaria no está en números rojos
  • WHEN: quiero retirar una cantidad inferior al límite de la tarjeta
  • THEN: la operación debe completarse sin errores o advertencias

Gherkin es un lenguaje fácil de usar del tipo GWT. Es similar al lenguaje natural y es posible utilizarlo para la realización de pruebas, pero también para escribir historias de escenarios de usuarios.

Su simplicidad permite a personas con poca experiencia en programación escribir diferentes casos. Las pruebas realizadas con Gherkin son almacenadas en archivos tipo .Feature, que deben ser versionados junto al código fuente de la aplicación que se está poniendo a prueba.

Estos archivos contienen los términos ya conocidos (Given, When, Then) y estos otros dos:

  • Feature: Es el nombre de la función que se va a testear, o el nombre de la prueba
  • Scenario: Es el escenario de la función que se va a poner a prueba

Herramientas BDD populares y conocidas

Las herramientas de pruebas de desarrollo más populares para crear y gestionar pruebas BDD son:

  • SpecFlow: marco .NET
  • Cucumber: framework Ruby 
  • Gauge: JavaScript, C#, Java, Python, framework Ruby 
  • Tricentis Tosca: marco de pruebas sin secuencias de comandos para API y GUI
  • Jasmine: marco de pruebas de JavaScript
  • Tricentis qTest Scenario: complemento BDD para Jira
  • Behat: framework PHP 
  • Concordion: framework Java
  • Squish GUI Tester: herramienta de pruebas BDD GUI para JavScript, Python, Perl, Ruby y Tcl)

Ventajas principales del enfoque BDD

Utilizando este enfoque, todos los miembros del equipo pueden leer y escribir pruebas de aceptación para el código que se está desarrollando. En este contexto, las ventajas percibidas son muy interesantes:

  • Mejor colaboración entre las partes, gracias al lenguaje compartido y sencillo de articular con el que tanto los propietarios del producto, como los desarrolladores y los tester tienen una visibilidad en profundidad de la progresión del proyecto.
  • Curva de aprendizaje corta.
  • Al ser un proceso no técnico por naturaleza, el BDD puede llegar a un público mucho más amplio.
  • Interacciones rápidas, ya que es posible responder rápidamente a los comentarios de los usuarios para añadir mejoras al software.
  • La adopción de BDD da confianza al equipo.
  • Elimina la ambigüedad y permite ahorrar tiempo al no cuestionar la interpretación de los requisitos y criterios de aceptación.
  • Se centra en las necesidades del usuario.
Fernando Fuentes

Artículos relacionados

Productos relacionados: