BDD o Behavior Driven Development es un proceso de desarrollo de software nacido desde el desarrollo guiado por pruebas. El BDD es una práctica derivada del Test-Driven Development (TDD), que también se guía por el enfoque Specification by Example (SBE). Dicho método define los requisitos y pruebas funcionales de la aplicación por medio de ejemplos realistas y no abstractos.

Debido al análisis brindado por BDD sobre el comportamiento del software en desarrollo, la documentación creada también se ve beneficiada. Tal como explica Tricentis, estos registros son fáciles de mantener y pueden ser consultados por cualquier persona relacionada a la aplicación.

Con ello, los marcos BDD buscan una mayor colaboración y comunicación entre los equipos técnicos y desarrolladores del software.

Además, BDD es compatible con las principales metodologías y herramientas de pruebas de automatización. Para conocer más detalles, te invitamos a leer el siguiente artículo de Tecnova.

Preparación de las pruebas en BDD

A partir de la información brindada por Inuuy podemos definir un marco a seguir para utilizar BDD.

Antes de realizar pruebas usando BDD, es de esperar que los desarrolladores y testadores de la aplicación conozcan:

• El punto de inicio de la prueba.
• Lo que se debe probar.
• No se debe probar.
• La frecuencia con que se debe realizar el proceso.
• El nombre de cada prueba y/o compilado de pruebas.
• El mecanismo para identificar fallos en las pruebas.

Generalmente, para evitar los problemas más comunes, el BDD usa las pruebas de unidad y aceptación.

Al realizar pruebas unitarias, se sugiere nombrarlas con oraciones completas.Vale decir, que el lenguaje con que se programen en este tipo de pruebas sea con verbos condicionales, como “Should” (en inglés). También se aconseja que las palabras sean terminologías comerciales claras y en orden de valor comercial. Las tareas de un software deben programarse según un orden determinado. Al programar un carro de compra, por ejemplo, se debe probar la función de “agregar productos” a ese carro y después la función de “comprar productos”.

En el caso de las pruebas de aceptación, al escribirlas deben venir en Scaled Agile Framework (SAFe) de una historia de usuario. Es decir, el “Interesado/Actor” (entidad que solicita un software) quiere una “capacidad/característica” que genere “beneficios/resultados positivos”.

De igual modo, es vital comprender la historia del usuario del proyecto. Esta historia de usuario es utilizada en la gestión del proyecto y el desarrollo de este. Es una manera informal de usar el lenguaje natural para describir las características del sistema de software.

Aunque todo depende del enfoque del proyecto, diferentes integrantes de áreas del desarrollo de software pueden escribir historias de usuarios. Hablamos de Directores, Líderes de proyecto, Desarrolladores, Ejecutores de pruebas, etc.

Gherkin, el lenguaje programático para BDD

El lenguaje usado para BDD es Gherkin. Gherkin es un lenguaje fácil de usar ya que es similar al lenguaje natural de las personas. Es posible utilizarlo para la realización de pruebas como para escribir historias de escenarios de usuarios.

Según el sitio Abstracta, este lenguaje, por su simplicidad, puede ser escrito por individuos sin grandes experiencias en el área de programación. Además, a pesar de que es común ver procesos realizados en Ingles, Gherkin permite más de treinta idiomas para trabajar.

Generalmente las pruebas realizadas con Gherkin son almacenadas en archivos “.Feature”. Estos archivos deben ser versionados junto al código fuente de la aplicación que se está testeando.

Estos archivos contienen los siguientes términos:

• Feature: Es el nombre de la función que se va a testear. También se puede considerar el nombre de la prueba.
• Scenario: Es el escenario de la función a poner a prueba.
• Given: Son las condiciones previas a la acción de la función.
• When: El conjunto de acciones que se ejecutarán
• Then: Los resultados que se esperan con el testeo. A partir de ellos, se realizan las validaciones.

Un ejemplo explicativo de estos tres últimos parámetros es el que brinda Tricentis:

• Given: Dado que me estoy registrando para una prueba gratuita (Contexto)
• When: Cuando envío los detalles requeridos (Sucede una acción)
• Then: Entonces recibo un enlace a la descarga. (Resultados)

Usualmente debe haber solo una función por archivo y en ella puede haber diversos escenarios de prueba.

Diseño de pruebas de aceptación bajo el enfoque BDD

A partir de lo indicado por Abstracta, estas pruebas pueden ser escritas por diferentes integrantes del equipo. Puede ser el Product Owner del proyecto o algún integrante de las áreas testeo o de desarrollo.

Una práctica aconsejable es que sea un trabajo en conjunto entre diferentes departamentos, aunque sea el Brainstorming. De este modo, hay una cooperación de diversos puntos de vista para el diseño de historias de usuarios y pruebas. Posteriormente, la persona responsable de las pruebas debe verificar que estén bien escritas y que cubran los parámetros requeridos para testear.

Para más información: