En los últimos años he participado en un par de iniciativas para automatizar pruebas en «ambientes corporativos». Cuando digo ambientes corporativos me refiero a organizaciones cuyo core de sistemas está implementado por algún  tipo de enlatado con cierto grado de customización (ERP, CRM, Core bancario, etc). Alrededor de este core la organización desarrolla aplicaciones satelitales que suelen actuar como canales implementado alguna funcionalidad complementaria al core. Estas aplicaciones satelitales/canales suelen tener una gran cantidad de requerimientos y cambios ya que son uno de los medios principales en la actualidad para permitir la innovación del negocio. A la hora de desarrollar estas aplicaciones aparece la necesidad de poder testearlas y que dicha prueba sea (al menos en parte) automatizada.

En particular he tenido la oportunidad de trabajar en contextos de instituciones bancarias y también del ámbito de las telecomunicaciones y en ambos casos he detectado situaciones/desafíos comunes que me parece son habituales en entornos corporativos.

En mi experiencia he identificado dos tipos de desafíos: los técnicos y los humanos.

En lo que respecta a desafíos técnicos el principal pasa por la dificultad de contar con un ambiente de pruebas sobre el cual uno pueda tener control de estados/datos.  En el escenario ideal yo quisiera poder contar con una instancia exclusiva y on-demand del core, cuyo estado pueda manipular a mi gusto sin impactar en otros equipos. Esto no es simple, ya que muchas veces el setup de estos sistemas core es bastante complejo y poco automatizado. Lamentablemente en ninguno de los casos que he trabajo he tenido esta posibilidad, lo cual me ha llevado a buscar soluciones alternativas.

Una situación que me he encontrado en todos los casos que participé es la presencia de un de ESB (enterprise service bus) que funciona como orquestador/integrador de mensajes entre los diversos sistemas de la organización incluido el core. De hecho es común que la interacción de los canales/satélites con el core se haga por medio de un ESB.  Si bien esto puede interpretarse como una complejización de la arquitectura, se supone que en general la simplifica. Al mismo tiempo representa una posible salida al problema del testing.

Entonces ante la imposibilidad de contar con un core para las pruebas (y también para el desarrollo) tenemos dos opciones. Una primera opción es mockear «a la salida» las interacciones con el core.

La otra opción sería hacer que el ESB devuelva respuestas mockeadas.

Algunos puntos a tener presente independientemente de la estrategia utilizada:

• Al utilizar una estrategia de mocking en este contexto es necesario tener algún mecanismo para detectar potenciales cambiamos en el sistema que estamos mockeando/emulando. Una estrategia posible es hace contract testing del sistema que estamos mockeando de manera que los tests de contrato se ejecuten periódicamente y nos alerten de eventuales cambios.
• En algún punto, previo al pasaje al ambiente productivo es necesario poder correr algún tests contra una instancia del core real.  En uno de los casos que me toco participar, la instancia de test del sistema core era tan inestable y distinta al core productivo que lo que se decidió hacer un despliegue canary a un servidor productivo, accesible solo internamente, y de esa forma probar directamente en producción.  Una vez realizada la validación, entonces se completaba el despliegue al resto de los servidores habilitando la aplicación al público en general.

Continuará…..
(en un futuro artículo me referiré a los «desafíos humanos de esta problemática»)