Seleccionar página

Tests de Componente, automáticos y aplicando BDD

Insights -> Tendencias y Actualidad

Asegurar la calidad de los componentes de un producto software son palabras mayores. Os contamos en este artículo cómo hemos resuelto nosotros este reto con los Tests de Componente, ejecutando todo de forma automática, partiendo de la integración continua del proceso e incluyendo el control del software de terceros involucrados.

Las primeras preguntas que pueden surgir leyendo el título me imagino que serán…¿BDD? ¿Y por qué? Empezaremos el viaje por aquí, aunque si ya estás familiarizado con lo relativo a BDD, puedes avanzar hasta el apartado en el que desmenuzamos cómo enfocamos los Tests de Componente.

BDD decíamos. Pues verás, son las siglas de “Behaviour Driven Development” o sea, desarrollo dirigido por comportamiento, que es una evolución de TDD o “Test Driven Development”, del cual ya os hemos hablado en alguna que otra ocasión, como en 5 preguntas básicas en pruebas automáticas.

Posiblemente con el nombre te hayas quedado como al principio, así que voy a contarte algún detalle más: BDD nació de la mano de Dan North gracias a su necesidad de probar ‘comportamientos’ a través de los tests que hacía. Digamos que el concepto de “test” se le quedaba corto, y descubrió que si describía los comportamientos que quería reproducir con las pruebas, resultaba mucho más claro para futuros desarrolladores lo que se estaba intentando comprobar y qué pasaba en el caso de que algo fallase.

BDD es una metodología ágil, que aplica a todo el proceso de desarrollo del software. Los test pasan a ser ‘escenarios’ o ‘comportamientos’, descritos en un lenguaje natural que puede ser fácilmente interpretado por todo el mundo, desde la parte de negocio a los desarrolladores.

El lenguaje más usado por la mayoría de los marcos de trabajo (“frameworks” como jBehave, Cucumber, Behave…) de BDD es Gherkin , que establece una serie de palabras clave (principalmente, Scenario para describir el comportamiento a probar, Given donde se establece el contexto, When para concretar el evento que desencadena el comportamiento, y Then explicando las consecuencias esperadas) y reglas de formato a través de las cuales podremos describir los escenarios.

El proceso a seguir en BDD comienza con la creación de una historia de usuario, que como ya sabemos, debería venir dada por el formato:

      • Quiero [funcionalidad]
      • Como [rol]
      • Para [beneficio]

Y que es donde aparecen todos los requisitos a cumplir. Una vez que la tengamos definida, llegaría el momento de establecer una serie de criterios de aceptación a través de diferentes escenarios usando Gherkin. Todos estos escenarios relativos a una misma historia de usuario, serán agrupados en un fichero al que llamaremos “feature”. Un ejemplo muy ilustrativo sería:

 

Tests de Componente

Ahora que ya tenemos una idea de para qué nos sirve BDD, vamos a contar un poquito de qué va eso de las pruebas de componente.

Este tipo de tests son los encargados de verificar el correcto funcionamiento de un componente software, como por ejemplo podría ser un proceso Java. Para ello, sería nuestra responsabilidad atender las siguientes cuestiones:

      1. Modificar los archivos de configuración que el componente lee al iniciarse, adecuándolos a nuestras necesidades y/o escenarios.
      2. Inyectar los datos precisos en las bases de datos (Oracle, MongoDB, etc.).
      3. Preparar los “mocks (simuladores) que interactúan con el componente en cada escenario, para enviar y/o recibir los mensajes necesarios.
      4. Iniciar y detener el proceso Java a voluntad.

A mayores de todo esto, también tendremos que tener instaladas en cada máquina las 3rd parties que pueda necesitar el proceso, y como guinda, debería ejecutarse todo de forma automática, asegurando también la integración continua del proceso.

Esquema de componentes involucrados - Tests de Componente

Esquema de componentes involucrados

En nuestro caso, para cumplir con esta exigente maraña de ‘requisitos’, las soluciones tecnológicas por las que optamos fueron:

Behave: Es el marco de trabajo (“framework”) de BDD que utilizamos, está programado en Python y se encarga del manejo de todos los mocks que hemos desarrollado, los clientes para el acceso a los datos de las 3rd parties, y ¡cómo no!, tiene el control total de la ejecución de todos nuestros tests.

Openstack: Nos habilita una Infraestructura como Servicio (IAAS) para crear las máquinas virtuales necesarias para poder lanzar pruebas de componente independientes entre sí. De esta manera, si tenemos 5 máquinas configuradas podremos paralelizar la ejecución de 5 features diferentes a la vez (una por cada máquina) con la consecuente optimización de tiempo. También al usar Openstack, nos aseguramos que todas nuestras máquinas comparten la misma configuración software y de sistema operativo.

Docker: Apostamos por tener “dockerizada” cada 3rd party que usa nuestro componente, así como las bases de datos y el propio componente. Esta solución nos resulta mucho más flexible que instalar estáticamente sobre la máquina cada una de las 3rd parties, y además nos permite resetear el entorno a un punto inicial, actualizar componentes fácilmente, y nos ahorra tiempo de configuración de cada uno de ellos.

Jenkins: Archiconocida herramienta que simplifica la integración continua y que nos facilita la vida permitiéndonos crear “jobs” para lanzar cada una de las “features” que tengamos diseñadas. De esta manera, cada feature (recordemos que estaban ‘hiladas’ con las historias de usuario) puede ejecutarse de forma autónoma e independiente.

Además, Jenkins nos da la oportunidad de lanzar automáticamente nuestros tests con nocturnidad y alevosía, aplicando el siguiente patrón:

      1. Construir imagen de docker del componente.
      2. Borrar todas las imágenes docker & contenedores de todas las máquinas de Openstack.
      3. Crear una imagen del componente a probar a partir de la rama de GIT con el código fuente en cuestión.
      4. Descargar las últimas imágenes de las 3rd parties (Oracle, MongoDB, Redis, etc..).
      5. Ejecutar los tests automáticos.

Vamos a terminar con un ejemplo que ilustre todo esto que os hemos explicado. Para ello, tomando como base el esquema de componentes anterior, si quisiéramos probar el proceso de Front End tendríamos:

Esquema de componentes involucrados - Tests de Componente

Esquema para la prueba automática del Componente Front End

 

En definitiva, el rendimiento conseguido con esta arquitectura de pruebas basada en los Tests de Componente ha sido muy superior al correspondiente a otros modelos más ‘tradicionales’ (¡y manuales!). Se han mejorado ostensiblemente los tiempos necesarios para asegurar la calidad del software (QA) y la detección de incidencias, no sólo en nuevos desarrollos sino también en regresivos de pruebas. Al utilizar BDD todos los involucrados, tanto de negocio como de tecnología, han expresado que ha mejorado su comprensión del alcance de las pruebas. Y en particular, los nuevos técnicos de pruebas han demostrado ser productivos en días frente a las semanas necesarias antes de introducir BDD.

Si estás interesado en más detalle sobre el rendimiento obtenido, las principales barreras encontradas o cómo conseguimos mantener al día el proceso, te animamos a lanzarnos tus consultas en los comentarios del artículo.

 

Fernando Casal

Fernando Casal

Fernando Casal es Ingeniero de QA en Panel Sistemas. Puedes visitar su perfil en Linkedin, o contactar con él vía e-mail a esta dirección.

Comentarios

1 Comentario

  1. Miguel Angel Nicolao

    ¡Interesante trabajo! ¡Enhorabuena!
    Ya que insistes … acepto la invitación:
    ¿Puedes contarnos algo más sobre las barreras encontradas?

    Gracias Fernando ?

    Responder

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This