Najim Aghmir El Yousfi

En BBVA Labs seguimos la pirámide de tests propuesta por Mike Cohn: tenemos un conjunto grande de test unitarios, fáciles de implementar y que se ejecutan en cada cambio en el código; un conjunto de tests de aceptación que se ejecutan siempre que se haya pasado todos los tests anteriores; y por último, los tests end-to-end que sólo se ejecutan cuando se desea liberar alguna funcionalidad.

La complejidad de la implementación de estos tests van en aumento según se sube en la pirámide. En los tests end-to-end, donde también se prueba la integración de servicios, se requiere levantar la infraestructura, los servicios a los que se desea testear y las servicios con los que se integra. El establecimiento del entorno del testeo, junto con la implementación y ejecución de los tests, es bastante más complejo que los test unitarios.

Adicionalmente al coste de ejecutar estos tests, aparece otro problema cuando un servicio cambia de formato de mensaje. Lo que se desea evitar es un despliegue tipo Big Bang (desplegar el servicio y todos sus dependientes a la vez) debido a este tipo de cambios rompe el despliegue continuo. Por tanto, durante un periodo de tiempo el productor de un servicio tiene que dar soporte a dos versiones del mensaje mientras los consumidores se van actualizando a la nueva, pero los tests del consumidor prueban solo con una única versión del productor del servicio.

Desde BBVA Labs hemos realizado un experimento para reducir el número de servicios a desplegar en los test y para asegurar, en un sistema de despliegue continuo, que la comunicación entre servicios de distintos dominios se mantiene a lo largo del ciclo de vida del producto software. Para este experimento se ha decidido evaluar las actuales herramientas para realizar Consumer Driven Contract testing (CDC testing o simplemente contract testing).