¿Cuál es el enfoque recomendado para hacer una prueba de integración para microservicios?

Para establecer una prueba de integración adecuada para microservicios, debe trabajar el mismo concepto que la prueba de integración de aplicaciones distribuidas, por ejemplo, aplicaciones empresariales u otras aplicaciones ‘monolíticas’. Simplemente ensamble piezas completas o parcialmente completas del sistema bajo prueba, prepare un accesorio de prueba bien definido y repetible y procese un conjunto repetible de pruebas en partes externas de la aplicación frente al cliente.

Tomemos un microservicio A que depende de otros dos servicios B y C. Debe establecer un entorno aislado donde el estado de A , B y C esté bien definido y pueda configurarse repetidamente. Por ejemplo, el estado / almacenamiento de B y C debe preinicializarse. Después de eso, solo ejecuta un conjunto de pruebas que prueban las API del microservicio A utilizando el conjunto habitual de herramientas de prueba REST / WebService, por ejemplo, SOAPUI o Chakram o una alternativa simple de xUnit para su lenguaje de programación.

Se burlan de los servicios de la API de los que depende el uso de restito. Otras alternativas incluyen rest-driver, wiremock y betamax.

El desafío obvio es la simulación / falsificación de API de terceros, nos encontramos con ese problema con mucha frecuencia en elastic.io al probar los componentes de microservicios de integración que se utilizan en nuestra plataforma. Normalmente usamos uno de restito, rest-driver o betamax. Simplemente trate los simulacros como parte de nuestro accesorio de prueba y asegúrese de estar actualizado con las nuevas versiones de API.

Le recomiendo que haga que los servicios puedan probarse todos los requisitos comerciales como componentes independientes. es decir, la elección del transporte y la serialización es un extra opcional, útil / requerido en la producción, pero hace que su vida sea más difícil para recrear escenarios y depurar la interacción de extremo a extremo de múltiples servicios.

Esto le permite realizar pruebas unitarias y pruebas de integración en un solo proceso (subproceso único) al hacer que un componente acceda directamente a otro. Para saber qué sucede entre dos o más componentes, revise el código en su depurador.

Esto es mucho más fácil de depurar y más rápido de probar que implementarlos como servicios reales.

Solo cuando esto funcione, debe probarlos nuevamente como servicios completos. Debe esperar que casi todos los errores se capturen / reproduzcan sin convertir sus componentes en servicios.