Cuando hablamos de BDD nos viene a la mente una “forma de automatizar tests”, pero en realidad Behaviour Driven Development va mucho más allá. Esta práctica de ingeniería comprende técnicas y herramientas que aplicamos desde el momento en que levantamos los requerimientos de nuestro producto (no de nuestro test sino de nuestro producto).

Ciertamente, definimos requisitos de forma más “testeable” pero nuestros objetivos al implementar BDD son “Build the right software” y “Build the software right“.

Casi ningún software que creamos es aislado, éste es parte de una estrategia de negocio y como tal, debe estar alineado a los objetivos del negocio. “Building the right software” se trata de construir el software correcto, el que va a cumplir con las expectativas del usuario y que va a resolver su problema/necesidad y que está perfectamente alineado a los objetivos del negocio.

“Building the software right” se trata de construirlo bien, con las mejores prácticas y asegurándonos que está correctamente diseñado y desarrollado, eso nos dará software más confiable y efectivo.

Entonces:

  • ¿Qué es exactamente Behaviour Driven Development?
  • ¿Cómo definimos requerimientos en BDD?
  • ¿Cómo pasamos de ejemplos y requisitos a Gherkin (Given / When / Then)?
  • y luego ¿Cómo pasamos de Gherkin al código (scenarios, steps, step definitions)?
  • ¿Es útil BDD como documentación?

Si eres de los que prefiere un video, puedes verlo aquí

 

¿Qué es Behaviour Driven Development?

Empecemos definiendo qué no es BDD. No es una metodología de desarrollo de software. De ninguna forma sustituye a Scrum o XP o cuál sea metodología que decidamos usar.

Es una práctica de ingeniería (un conjunto de prácticas y técnicas) que podemos implementar en nuestro proceso de desarrollo, independientemente de cuál es la metodología que usemos. Estas prácticas se aplican para:

  1. Generar conversaciones alrededor de ejemplos concretos para entender cómo los features proveen valor al negocio.
  2. Expresar requerimientos de forma más “testeable” en un lenguaje que tanto stakeholders como equipo de desarrollo puede entender.
  3. Convertir requerimientos en test automatizados que guían el desarrollo, verifican/validan el feature y se convierte en documentación.

 

¿Qué buscamos con BDD?

Buscamos

  • “Build the right software” y “Build the software right” (conceptos mencionados anteriormente).
  • Colaboración y entendimiento colectivo (stakeholders, business analysts, software developers, and testers). Cuando colaboramos todos en el diseño de la solución, garantizamos que todas las capacidades de nuestro equipo están siendo aprovechadas al máximo. Muchas veces el cliente/usuario/sponsor llega a nosotros no solo con el problema sino con lo que considera que es la solución, y durante la definición de requisitos (y refinamiento) surgen más ideas de parte de diseñadores UX, desarrolladores (que aportan su technical know-how para diseñar lo más óptimo) y testers (y así tenemos la oportunidad de verificar y validar desde el inicio) para construir esta solución.
  • Entregar más valor al identificar, entender y construir lo que más importa en el negocio.
  • Entregar software más confiable y efectivo (asegurar que está bien diseñado y desarrollado).

 

¿Qué testeamos?

Testeamos que el producto se comporte como esperamos. Nuestros tests describen cómo se espera que el producto se comporte (desde el punto de vista del usuario), no describe detalles de implementación.

Nuestros tests están escritos en un lenguaje que un usuario/stakeholder puede entender y darnos feedback acerca del comportamientoo esperado del System Under Test.

Testeamos features (o bugs), no componentes (ni clases). Para testear componentes y clases tenemos los integration y los unit test.

Es importante destacar que el BDD no sustituye los unit test ni los integration tests. Queremos asegurar la calidad de nuestro software y para ello requerimos distintos tipos de tests así como una visión completa de la calidad de nuestro producto.

 

Definiendo requerimientos en BDD

Para hablar de requerimientos, comencemos definiendo 2 conceptos importantes: Capabilities y features.

Capabilities les da a los usuarios/stakeholders la habilidad de realizar alguna tarea útil o completar algún objetivo comercial. La habilidad de “hacer algo” (independientemente de cómo lo vamos a implementar). Por ejemplo, “the ability to purchase a foreign currency” es un capability.

Feature representa una funcionalidad de software que construimos para soportar el capability. “Purchase a foreign currency cash” es un feature.

Un feature es una funcionalidad tangible y entregable que ayuda al negocio a alcanzar sus objetivos. ¿Cómo identificamos si es o no un feature? Es:

  • Una acción concreta que el usuario puede realizar en el sistema.
  • Algo que cambia el estado del sistema.
  • Algo que hace que el sistema interactúe con un tercero (third-party).

Para definir requisitos con BDD usamos la técnica de “the 3 amigos” en workshops de requerimientos. Los 3 amigos son:

  • Equipo de producto: analistas de negocios, product owner. También se extiende hasta clientes/usuarios/sponsors que participan activamente en la construcción de nuestro software.
  • Desarrolladores: equipo de desarrollo.
  • Testers.

En estos workshops de definición de requerimientos usamos el Example Mapping (una técnica de desarrollo guiado con ejemplos). Muchas veces estamos intentando definir requerimientos y preguntamos “puedes darme un ejemplo?”

Imagina que somos un banco y nuestros clientes quieren comprar moneda extranjera.

 

En este artículo hablamos con más detalles del example mapping. El objetivo de esta técnica es descubrir ejemplos, agruparlos en Reglas de negocio y en features.

A partir de estos ejemplos y features vamos a crear nuestras historias de usuario.

Usemos una historia en este ejemplo:

Cuando diseñamos la historia, los ejemplos y las reglas ya identificadas se convierten en nuestro Criterio de Aceptación del Usuario.

 

De ejemplos a Gherkin (Given / When / Then)

Cuando tenemos nuestros ejemplos, diseñamos nuestro escenario de test. Cada escenario tiene pasos que expresamos en lenguaje Gherkin: Given, When, Then, And, and But.

Gherkin es un lenguaje no técnico que puede ser leído por cualquier persona (como lenguaje natural) y que nos permite expresar comportamientos.

Los pasos más importantes son:

  • Given: son las precondiciones para un escenario y preparación del ambiente para ejecutar nuestro test.
  • When: la acción a realizar por el usuario (la acción que vamos a testear).
  • Then: el resultado esperado. ¿Cuál es la respuesta que esperamos de parte del sistema?

Siguiendo con nuestro ejemplo del banco y de nuestros clientes que quieren comprar moneda extranjera, diseñamos este escenario:

Nuestro ejemplo con data de ejemplo en lenguaje Gherkin:

Luego escribimos el test de forma más genérica, separando la data y convirtiéndola en variables que nos van a permitir correr el mismo test con distintos data set:

De Gherkin al código (scenarios, steps, step definitions)

Cuando tenemos nuestros tests escritos en Gherkin, podemos convertirlos en especificaciones ejecutables (código fuente). De esta forma podemos automatizar nuestros criterios de aceptación.

Para lograr estas especificaciones ejecutables, usamos:

  • Feature file
  • Page Object Model
  • Step definitions

 

Aquí puedes profundizar acerca de Gerkin en código fuente siguiendo el mismo caso de estudio de este artículo.

 

Usando tests BDD como documentación

  • Nuestro tests escritos en Gherkin funcionan como parte de la documentacion. No es una documentaci’on completa por s’i, pero contribuye a nuestra base de documentacion.
  • Siempre esta actualizada respecto a nuestro system under test (o “casi siempre” actualizada) y funcionando. Podemos confiar en que esta documentacion esta siendo actualizada constantemente.
  • Es fácil de leer y esta ilustrada con ejemplos. Lo que significa que alguien que se incorpora a nuestro equipo puede comenzar a entender como funciona, que hacemos (desde el punto de vista de negocio) y lo que los usuarios/clientes esperan de nuestro producto/servicio. En algunos casos tambien nos ayuda a saber como fueron implementados nuestros features.
  • Tambien nos ayuda a tener status sobre nuestro proyecto. En un momento determinado podemos saber cuantos features tenemos (en nuestro system under test) y cuantos escenarios estan automatizados vs cuantos siguen siendo manuales.

Conclusiones

Es una práctica de ingeniería, no una metodología.

Testeamos comportamiento (features y/o bugs), no componentes ni clases.

Colaboramos testers, desarrolladores y equipo de producto con los clientes/usuarios/stakeholders para crear las mejores soluciones.

Entregamos software bien diseñado y construido y que, a su vez, es el software correcto, el que va a cumplir con las expectativas del usuario y va a resolver su problema/necesidad y está perfectamente alineado a los objetivos del negocio.

 

Referencias

Libro BDD in Action. John Ferguson Smart.

Libro Agile Testing Condensed. Lisa Crispin y Janet Gregory.

Web Zerobank (utilizada en los test automatizados)

Código fuente BDD Currency