PDF de programación - Automatizacion de pruebas de integracion en arquitecturas orientadas a servicios

Automatizacion de Pruebas de Integración en

Arquitecturas Orientadas a Servicios

Lic. Facundo Chambó, Mg. Patricia Bazán, Lic. Juan Ramón Cortabitarte

Universidad Nacional de la Plata, Facultad de Informática

Resumen En arquitecturas orientadas a servicios, las pruebas de inte-
gración cumplen un papel muy importante ya que es necesario validar
tanto los escenarios de prueba nuevos como los ya existentes para evitar
que los nuevos desarrollos generen fallos en escenarios que ya funciona-
ban. Estas pruebas pueden ser manuales o automáticas. El problema con
las pruebas de integración automáticas es que requieren ser desarrolladas
y no es posible comenzar con su desarrollo hasta que esté avanzado el
desarrollo de la funcionalidad. Esto hace que la automatización retrase
la puesta en producción del nuevo desarrollo, generándole un perjuicio al
negocio. Este artículo propone un framework el cual permita automatizar
las pruebas de integración de aplicaciones en arquitecturas orientadas a
servicios sin necesidad de que la funcionalidad de la misma se haya co-
menzado a desarrollar y así reducir el tiempo de la puesta en producción.

Keywords: calidad, automatizacion, http, arquitecturas orientadas a
servicios, framework

1.

Introducción

Este artículo fue escrito como resultado de mi tesina de grado correspondiente
a la carrera de Licenciatura en Sistemas en la Facultad de Informática de la
Universidad de La Plata. La misma fue dirigida por Mg. Patricia Bazán y mi
asesor profesional fue Lic. Juan Ramón Cortabitarte.

Asegurar la calidad de una aplicación desarrollada sobre una arquitectura

SOA requiere de al menos tres tipos de prueba [1]:

Pruebas Unitarias: aseguran que cada componente trabaja correctamente
asumiendo que la integración con otros servicios funciona correctamente.
Esto se realiza utilizando mocks de todos los componentes externos (invoca-
ciones a otros servicios, acceso a las bases de datos, etcétera). El objetivo de
estas pruebas es probar de forma aislada componentes internos del servicio
como métodos, clases o procedimientos.
Pruebas de Integración: aseguran que la comunicación entre servicios funcio-
na correctamente consumiendo la aplicación y analizando los resultados sin
validar su comportamiento interno.

2

Pruebas de Aceptación: aseguran que la aplicación cumple correctamente
con los objetivos para los cuales fue creada1. Estos objetivos no siempre
pueden ser probados de forma automática (o bien su implementación es
muy costosa), por lo que es común ver que estas pruebas se realicen de forma
manual. Este tipo de prueba se utiliza para validar el comportamiento de los
servicios creados (o modificados) dentro del sistema completo en un escenario
de prueba integral.

El aporte de este trabajo es construir un framework para dar soporte a la
automatización de pruebas de integración en el desarrollo de software en ar-
quitecturas orientadas a servicios sin necesidad de que la funcionalidad de la
misma se haya comenzado a desarrollar y así reducir el tiempo de la puesta en
producción y la dependencia entre diferentes equipos de desarrollo.

Para lograr este objetivo, será necesario utilizar los componentes de infraes-
tructura existentes para rutear las invocaciones HTTP e instalar una aplicación
web con sus repositorios de persistencia.

2. Framework TestIA (Testing Information by

Automation)

2.1. Objetivo

El framework TestIA busca dar soporte a la automatización de las pruebas

aportando las siguientes herramientas:

Permitir un control completo sobre la ejecución de un determinado escenario
sin necesidad de depender que en la implementación de las funcionalidades
exista código especial para una prueba.
Brindar independencia al desarrollo de las pruebas de la implementación de
la funcionalidad. Esto ayuda a que la automatización de las pruebas pueda
seguir el ritmo del equipo que implementa la funcionalidad.
Auditar los servicios involucrados en la ejecución de un escenario de prueba.

La ejecución de un escenario de prueba dentro de la arquitectura del frame-

work, está basado en cuatro grandes pasos:

Cada aplicación debe mantener, mediante un header HTTP, un dato que
identifica el escenario de prueba actual y debe propagarlo por cada invocación
que realiza.
Como se ilustra en la Figura 3, el ESB busca ese dato en el encabezado de la
invocación y, si lo encuentra, redirige al componente web del framework. En
caso de que el ESB deba invocar al servicio de destino, se agrega un header,
que el ESB luego remueve, para evitar que vuelva a redirigir al componente
web del framework y se genere un loop infinito.

1 También llamados Criterios de Aceptación

3

Figura 1. Cada servicio debe reenviar el header recibido a todos los servicios que éste
invoque.

El componente web, en base al origen y destino de la invocación y al escenario
que se está probando (el cual se identifica por el header HTTP), decide qué
hacer con la invocación.
Cada escenario de prueba puede requerir un determinado conjunto de vali-
daciones. El componente web contiene un conjunto estándar de validaciones,
pero, en caso de ser necesario, contiene un mecanismo de plugins para que
se añadan otras validaciones.

3. Arquitectura

Se comenzará por definir la arquitectura del framework, es decir, sus compo-

nentes y la relación que deberá existir entre los mismos (ver la Figura 2):

Figura 2. Arquitectura general.

4

ESB: su función principal es la de discernir cuáles invocaciones corresponden
a ejecuciones de casos de prueba y cuáles no.[2]
Aplicación web: su función es identificar a qué caso de prueba corresponde
una invocación y, en base a la configuración del mismo, tomar las acciones
necesarias.
Repositorio de casos de prueba: almacena los casos de prueba y las configu-
raciones a realizar para cada interacción entre componentes.
Repositorio de resultados: almacena los resultados de las ejecuciones de los
casos de prueba. Aquí es posible consultar: tiempos de respuesta, resultado
de las validaciones, respuestas de los servicios (originales o no).
Repositorio de mocks: almacena las respuestas precargadas que la aplicación
puede devolver como respuesta a la invocación de un servicio.

Esta arquitectura implica que se cumplan las siguientes precondiciones para

la correcta ejecución de las pruebas:

Todas las invocaciones a servicios deben pasar por el ESB (ver la Figura 3)
[3]
Todas las aplicaciones o servicios que consuman otros servicios deben incluir
en sus invocaciones el header recibido en la invocación original.

Figura 3. Comportamiento normal del ESB.

Teniendo esto en cuenta y ayudado por el protocolo de red, el ESB, es capaz
de diferenciar aquellas invocaciones que pertenecen a la ejecución de un caso de
prueba de aquellas que pertenecen a una ejecución real.

Existe un repositorio de escenarios de prueba identificados unívocamente.
Este repositorio contiene las distintas invocaciones a los servicios y la operación
a realizar ante cada invocación.

3.1. Estructuras de datos

Dependiendo del dominio de aplicación, los datos requeridos para representar
la ejecución de un escenario de prueba pueden variar, pero este framework define
la siguiente estructura mínima:

5

Identificador del escenario de prueba: este es el dato que identifica unívoca-
mente al escenario.
Invocaciones: consiste en una lista de invocaciones a servicios. Cada invoca-
ción a un servicio debe contener, al menos, una identificación del servicio y
la acción que se debe realizar.
Servicios: esta estructura de datos describe cómo se debe invocar a un de-
terminado servicio. Por ejemplo, se debe especificar el método HTTP que se
debe utilizar, la ubicación del servicio (o su URL) y la estructura de datos
que debemos enviar.
Acciones: definen qué acción se realizará con la invocación. Las acciones de-
ben estar tipificadas y cada tipo de acción contiene una estructura diferente.
Si bien es posible agregar nuevos tipos de acciones, los dos tipos de acciones
básicos definidos por el framework son:
• Validación de los datos de respuesta: esta acción se ejecutará cuando el
servicio de destino haya devuelto su respuesta y se ejecutarán validacio-
nes sobre los datos de la misma.
• Retornar una respuesta predefinida: en lugar de invocar al servicio, se
retorna una respuesta del repositorio, simulando una respuesta real del
servicio.

{

“scenario”: {

“id”:1,
“invokations”: [{

“service_id”:123,

“actions”: [{

“type”: “VALIDATION”,

“expression”: “some_field == true”

}]
},{

“service_id”:1234,
“actions”:[{
“type”: ”MOCK”,
“mock_id”: 1432
}]

}]

}

}

Figura 4. Ejemplo de la representación de un scenario.

Antes de iniciar la ejecución de un escenario de prueba el robot de automa-
tización debe obtener un identificador de dicha ejecución. Este dato es el que
utilizará el componente web para buscar el escenario de prueba en el repositorio.

6

{

}

“service”: {
“id”:123,
“host”: “info.unlp.edu.ar”,
“port”: “8080”,
“method”: “GET”,
“content_type”: “application/json”,
“accept”: “application/json”

Figura 5. Ejemplo de la representación de un servicio.

A partir de este identificador es posible obtener del repositorio tanto la confi-
guración del escenario de prueba como los resultados de las validaciones de las
invocaciones a los servicios.

POST /scenario/1/execution

--------------------------

HTTP/1.1 201 CREATED

{“execution_id”: 123}

Figura 6. Ejemplo de la creación de una ejecución de un escenario de prueba.

3.2. Ejecución

Durante la ejecución de un escenario de prueba, la aplicación de prueba
invoca el servicio al igual que lo hace la aplicación productiva, pero agrega el
identificador de ejecución del escenario de prueba como valor del header HTTP
X-TestIA.

Este agregado en la metadata del protocolo HTTP hace que el ESB detecte
que se trata de una prueba y redirija el tráfico al componente web del framework.
Éste busca en el repositorio la configuración del caso de prueba. Por ejemplo, si
la configuración del escenario define que es necesario ejecutar validac