Superando los desafíos de las pruebas de microservicios y maximizando los beneficios

Los microservicios han sido una tendencia de la industria durante años, pero las organizaciones no están aprovechando los beneficios del enfoque y están luchando con lanzamientos fallidos. Estas fallas a menudo se reducen a la dificultad de probar las interfaces entre los servicios para obtener la calidad, la seguridad y el rendimiento que se espera.

Al final, es un fracaso probar estas API de una manera lo suficientemente sólida. El lado positivo es que los conceptos de prueba y las soluciones entre las pruebas de SOA heredadas y las pruebas de microservicios son los mismos. Si puede resolver sus problemas de prueba de API, puede mejorar sus lanzamientos de microservicios.

Los microservicios presentan nuevos desafíos

En estos días, es común ver cientos, si no miles, de microservicios agrupados para definir una arquitectura moderna.

Los sistemas empresariales altamente distribuidos tienen implementaciones grandes y complejas, y esta complejidad en la implementación a menudo se considera una razón para NO implementar microservicios. De hecho, la complejidad dentro del monolito que está descomponiendo se está desmoronando en un entorno de implementación aún más complejo.

Para decepción de los no iniciados, la complejidad en realidad no desaparece y, en cambio, se está transformando en un nuevo tipo de complejidad.

Si bien los microservicios prometen aumentar la eficiencia del desarrollo paralelo, presentan su propio nuevo conjunto de desafíos. Aquí hay unos ejemplos.

• Muchas más interacciones para probar en la capa de la API, mientras que antes las pruebas de la API se limitaban solo a probar puntos finales expuestos externamente.
• Obstáculos de desarrollo paralelo que limitan los beneficios de tiempo de comercialización de romper el monolito. Las dependencias de otros servicios y entornos de implementación complejos reducen el paralelismo en la realidad.
• Impactos en los métodos tradicionales de prueba que tuvieron éxito dentro del monolito (como las pruebas de interfaz de usuario de extremo a extremo) ahora deben cambiar a la capa API.
• Más puntos potenciales de falla debido a los datos y la computación distribuidos, lo que hace que la resolución de problemas y el análisis de la causa raíz sean difíciles y complejos.

3 pasos clave para las pruebas de microservicios

¿Cuáles son los tres pasos clave para las pruebas de microservicios? Para describirlos simplemente, estos pasos son:

1. Record
2. Monitorear
3. Control

El registro, la supervisión y el control lo ayudarán a implementar enfoques de prueba que descubre qué pruebas crear al mismo tiempo que lo ayuda a automatizar las pruebas de componentes cuando hay API posteriores de las que necesita aislarse.

La tecnología que permite hacer esto es la virtualización de servicios. La virtualización de servicios da vida a estos 3 conceptos a través de una característica fundamental: los servidores proxy de mensajes.

El uso de servidores proxy de mensajes en su entorno de implementación le permite monitorear y registrar los flujos de mensajes entre las API, así como también controlar los destinos donde se envían los mensajes.

¿Cómo funciona un proxy de mensajes?

Está diseñado para escuchar un punto final o cola determinado y luego reenviar los mensajes que recibe a un punto final o cola de destino. Básicamente, es un intermediario para sus API. Usted elige activamente inyectar uno entre sus sistemas integrados. Una vez que esté en su lugar, estará listo para comenzar a aprovecharlo.

Pruebas de API y microservicios

Prueba de API y superar los desafíos que representan no es tan diferente ya sea que su entorno esté altamente distribuido, algo distribuido o mayormente monolítico. Cuanto mayor sea el número de integraciones que existan, más agudos serán algunos de los desafíos, pero los enfoques fundamentales son los mismos.

Al pensar en un API o microservicio como una caja negra, podemos desglosarlo en los clientes de su servicio y las dependencias de su servicio. Probar su API como una caja negra significa que su arnés de prueba está actuando como un cliente para su servicio cuyo trabajo es verificar que recibe las respuestas correctas. Las dependencias son con lo que su servicio necesita integrarse para funcionar correctamente. Se deben realizar optimizaciones tanto en el lado del cliente como entre las dependencias.

Antes de explorar estas optimizaciones, comencemos en la fase de diseño, donde se planifica el microservicio y donde debe comenzar la estrategia de prueba.

El ciclo de vida del microservicio

Fase de diseño: definir requisitos de claridad

Una mejor práctica de desarrollo de API bien aceptada es implementar una definición de servicio durante la fase de diseño. Para los servicios RESTful, se suele utilizar la especificación OpenAPI.

Sus clientes utilizan estas definiciones de servicio para comprender qué recursos y operaciones admite su servicio y cómo su servicio espera recibir y enviar datos. Dentro de las definiciones de servicio para los servicios REST habrá esquemas JSON que describen la estructura de los cuerpos de los mensajes, para que las aplicaciones cliente sepan cómo trabajar con su API.

Pero las definiciones de servicio no solo son importantes para ayudar a otros equipos a comprender cómo funciona su API, sino que también tienen un impacto positivo en su estrategia de prueba.

Puede pensar en la definición de servicio como un contrato. Esa es la base para comenzar a construir una estrategia para el gobierno de API. Uno de los mayores desafíos en las pruebas de API, al igual que cualquier prueba de software, es lidiar con el cambio.

Con la popularidad de las prácticas ágiles, el cambio nunca ha sido tan rápido. Hacer cumplir estos contratos es el primer paso para poner orden en el caos cuando intentas pelear con muchos equipos que están creando API y luego esperan que todas estas API funcionen bien entre sí.

Validación y cumplimiento de contratos

¿Cómo se hace para hacer cumplir un contrato?

Como parte de cualquier suite de regresión automatizada, debe verificar si la definición de servicio que ha escrito su equipo tiene algún error. Swagger y OpenAPI tienen sus propios esquemas que definen cómo se debe escribir la definición del servicio. Puede usarlos para automatizar estas comprobaciones al principio del ciclo de vida de desarrollo de la API.

Luego, además de verificar el contrato en sí, desea verificar que las respuestas que devuelve su servicio también se ajusten al contrato. Su marco de prueba de API debe tener soporte incorporado para detectar instancias en las que su API devuelve una respuesta que se desvía del esquema de definición de su servicio.

Piensa en esto, de esta manera. Un automóvil se compone de miles de piezas individuales que deben encajar perfectamente.

Si el equipo responsable de la unidad de potencia entrega un motor que se desvía de las especificaciones de diseño, es probable que tenga grandes problemas cuando intente conectar la transmisión que construyó un equipo diferente porque estaban haciendo referencia al diseño del motor para saber donde los pernos deben alinearse.

Eso es lo que estás buscando aquí. Estos son los tipos de problemas de integración que un buen gobierno de API puede ayudarlo a evitar. Diseñar y cumplir con estos contratos debe ser una de las primeras preocupaciones de su práctica de prueba de API.

Los contratos de definición de servicios también pueden ayudar a que su proceso de prueba sea más resistente al cambio. El tiempo que lleva refactorizar los casos de prueba para los cambios en una API podría tener un gran impacto en las pruebas, de modo que se excluya del sprint.

Esto es un riesgo tanto para la calidad como para la seguridad. También significa tiempo no programado para pruebas adicionales. Cuando se usa un marco de prueba de API, debe ayudar a los equipos a refactorizar en masa los casos de prueba existentes a medida que cambia el diseño de una API para que puedan mantenerse al día con el ritmo rápido de las pruebas ágiles y en sprint. Los contratos de servicio y las herramientas adecuadas pueden hacer que esto sea mucho menos doloroso.

Fase de implementación: aplicar las mejores prácticas

El desarrollo de microservicios no implica un pase gratuito para omitir las pruebas unitarias. El código es código y las pruebas unitarias son una práctica de calidad fundamental. Ayuda a los equipos a detectar regresiones de forma rápida, temprana y de una manera que los desarrolladores pueden corregir fácilmente, sin importar el tipo de software.

La fea verdad es que los equipos de software con prácticas de prueba unitaria inexistentes o reactivas tienden a tener resultados de mala calidad. Los gastos generales de las pruebas unitarias se consideran demasiado y, por lo tanto, muchos gerentes y líderes no le dan prioridad.

Esto es desafortunado porque el mercado de herramientas ha madurado donde la vida de un desarrollador es mucho más fácil y más productiva mientras que las pruebas unitarias y la compensación entre costo y calidad es mucho menor de lo que solía ser. Las pruebas unitarias forman la base de una práctica de prueba sólida y no deben ser defraudadas.

Además, las prácticas de calidad del software para desarrolladores han madurado con estándares de codificación dedicados para el desarrollo de API. En 2019, la organización internacional sin fines de lucro OWASP lanzó el OWASP Top 10 API Estándar de seguridad.

Los estándares de codificación como este ayudan a los equipos de microservicios a evitar antipatrones comunes de seguridad y confiabilidad que podrían introducir riesgos comerciales en sus proyectos. Intentar adoptar un estándar de codificación sin herramientas es casi imposible.

Afortunadamente, las herramientas modernas de análisis estático, también conocidas como herramientas de prueba de seguridad de aplicaciones estáticas (SAST), se mantienen al día con los estándares de la industria y serán compatibles con este estándar. Los desarrolladores pueden escanear su código mientras lo escriben y como parte de su proceso de integración continua para asegurarse de que no se pierda nada.

Fase de prueba de componentes: uso de proxies para dependencias de API

La prueba de componentes implica probar su microservicio de forma aislada. Lograr un verdadero aislamiento tiene desafíos como saber qué hacer con las dependencias de su microservicio. Además, una de las cosas más difíciles de anticipar como desarrollador de microservicios es comprender exactamente cómo otros sistemas utilizarán su API.

Es probable que las aplicaciones cliente de su API encuentren usos creativos de sus microservicios que nunca se consideraron. Esto es tanto una bendición comercial como una maldición de ingeniería, y exactamente por qué es importante gastar energía para comprender los casos de uso de su API.

El control de la API durante la fase de diseño es un primer paso importante, pero incluso con contratos bien definidos y la validación automatizada del esquema de las respuestas de su microservicio, nunca podrá predecir por completo cómo van las necesidades del producto de extremo a extremo. evolucionar y cómo afectará eso a los microservicios dentro de su dominio.

La grabación, el monitoreo y el control lo ayudarán a implementar enfoques de prueba que descubran de manera eficiente qué pruebas se necesitan y, al mismo tiempo, lo ayudarán a automatizar las pruebas de componentes cuando haya API posteriores de las que necesite aislarse. La tecnología habilitadora hacer esto es virtualización de servicios.

La virtualización de servicios da vida a estos tres conceptos a través de una característica fundamental: los servidores proxy de mensajes. El uso de proxies de mensajes le permite monitorear y registrar los flujos de mensajes entre las API, así como controlar los destinos donde se envían los mensajes.

Servicios orquestados vs coreografiados

Los servicios orquestados y coreografiados (o reactivos) son términos sofisticados que describen patrones de mensajería síncrona o asíncrona.

Si su servicio se comunica mediante un agente de mensajes con protocolos como AMQP, Kafka o JMS, entonces está probando un servicio coreografiado o reactivo.

Si está probando una interfaz REST o GraphQL, es un servicio orquestado o síncrono.

A los efectos de esta publicación, realmente no importará con qué protocolo y patrón de intercambio de mensajes se esté enfrentando. Sin embargo, es posible que le resulte más difícil aplicar estos principios con la mensajería asíncrona si su marco de pruebas de API no es compatible con los protocolos que su organización ha elegido adoptar.

Capturar escenarios de uso del cliente

Es difícil para un equipo de microservicios predecir cómo otros equipos usarán su API. Sabemos que las pruebas totalmente integradas y de extremo a extremo son costosas y lentas. El uso de las capacidades de proxy de mensajes que se encuentran en las herramientas de virtualización de servicios le permite registrar el tráfico proveniente de las aplicaciones cliente ascendentes para que pueda capturar escenarios de uso realistas que mejoran significativamente su conocimiento de qué pruebas deben ejecutarse dentro de su canalización de CI/CD sin requerir que esas aplicaciones cliente estar siempre presente para desencadenar ese tráfico.

En otras palabras, la grabación le permite reproducir estos escenarios de integración para pruebas de regresión automatizadas que son mucho más simples y fáciles de administrar que pedirles a los clientes que ejecuten sus pruebas, que prueban transitivamente su API. Esta es la razón por la que las herramientas que combinan la virtualización de servicios con las pruebas de API son tan populares. Facilitan el registro de este tráfico de API y luego lo aprovechan para pruebas de escenarios de API que están bajo su control.

Hacer que las dependencias sean manejables

Probar su servicio rápidamente se vuelve difícil debido a su dependencia de otras API en un entorno de prueba, lo que genera problemas de disponibilidad, datos de prueba realistas y capacidad.

Esto puede hacer que el esfuerzo de prueba quede fuera del sprint y dificultar que los equipos detecten problemas de integración lo suficientemente pronto como para que tengan tiempo de resolverlos. Este es el caso de uso tradicional para la virtualización de servicios, donde la tecnología permite simular o simular las respuestas de las API descendentes (al hacerlo, crea una versión virtual del servicio) proporcionando aislamiento para que pueda probar completamente su API antes y más fácilmente con su canalización de CI/CD.

Cuando los proxies de mensajes se implementan en un entorno, los equipos pueden registrar el tráfico de la API y luego crear servicios virtuales que respondan fiel y realistamente al microservicio (incluidas las transacciones con estado en las que la dependencia simulada debe manejar correctamente las operaciones PUT, POST y DELETE) sin tener la información real. dependencia disponible.

La virtualización de servicios con estado es una característica importante para crear el servicio virtual más realista que cubra todos sus casos de uso de prueba.

Fase de prueba integrada: control del entorno de prueba

Ahora vamos a alejar un poco más el alcance de la prueba a la prueba de integración. En esta etapa, a veces denominada prueba de integración del sistema o etapa SIT, el entorno de prueba es un entorno similar al de producción que garantiza que no se pase por alto ningún defecto.

Debe esperar que los proxies de mensajes proporcionen control sobre si desea una conexión aislada o del mundo real a las dependencias. Otro aspecto del control es asegurarse de que los servidores proxy de mensajes se puedan administrar fácilmente a través de la API. Las organizaciones con una gran madurez en sus procesos de CI/CD están automatizando los flujos de trabajo de implementación y destrucción en los que el control programático del proxy de mensajes es un requisito imprescindible.

¿Qué optimizaciones puede extraer de la visibilidad, u observabilidad, que exponen los servidores proxy de mensajes cuando se encuentra en la fase de prueba de integración?

Aquí es donde las capacidades de monitoreo son esenciales para una solución de virtualización de servicios que admita pruebas automatizadas. El monitoreo de los proxies de mensajes expondrá el funcionamiento interno de estos flujos de trabajo complejos para que pueda implementar una mejor prueba que le diga dónde está el problema, no solo que existe un problema.

Considere, por ejemplo, un sistema de procesamiento de pedidos que necesita verificar múltiples servicios posteriores como sistemas de inventario, facturación y envío para cumplir con un pedido. Para una entrada de prueba dada, puede afirmar contra cierto comportamiento detrás de escena que ayuda a los desarrolladores a identificar por qué falla una prueba. Cuando su equipo dedica menos tiempo a averiguar por qué ocurrió un problema, tienen más tiempo para solucionarlo.

Cinco consejos para probar microservicios

A continuación, se incluyen cinco consejos que le ayudarán a desarrollar una estrategia de prueba de microservicios. Tenga en cuenta que estas son sugerencias. Como todos los tipos de planes de prueba, debe considerar las especificaciones de su configuración.

1. Considere cada servicio como un módulo de software. Realice pruebas unitarias en un servicio como lo haría en cualquier código nuevo. En una arquitectura de microservicios, cada servicio se considera una caja negra. Por lo tanto, pruebe cada uno de manera similar.
2. Determine los vínculos fundamentales en la arquitectura y pruébelos. Por ejemplo, si existe un vínculo sólido entre el servicio de inicio de sesión, la interfaz que muestra los detalles del usuario y la base de datos para obtener los detalles, pruebe estos vínculos.
3. No se limite a probar escenarios de caminos felices. Los microservicios pueden fallar y es importante simular escenarios de fallas para generar resiliencia en su sistema.
4. Haz tu mejor esfuerzo para probar en todas las etapas. La experiencia ha demostrado que los probadores que utilizan una combinación diversa de prácticas de prueba, comenzando en el desarrollo y progresando a través de alcances de prueba más grandes, no solo aumentan la posibilidad de que los errores se revelen, sino que lo hacen de manera eficiente. Esto es particularmente cierto en entornos virtuales complicados donde existen pequeñas diferencias entre varias bibliotecas y donde la arquitectura de hardware subyacente puede producir resultados imprevistos e indeseables a pesar de la capa de visualización.
5. Utilice “pruebas canarias” en código nuevo y pruebe en usuarios reales. Asegúrese de que todo el código esté bien instrumentado. Y también utilice toda la supervisión que ofrece su proveedor de plataforma. Esto cumple con las pruebas de "cambio a la izquierda" con las pruebas de "cambio a la derecha" porque también está probando "en la naturaleza".

Desmitificando los Microservicios

Los microservicios llegaron para quedarse. Desafortunadamente, las organizaciones no están aprovechando los beneficios del enfoque. Todo se reduce a la dificultad de probar las interfaces entre los sistemas distribuidos (es decir, las API) para obtener la calidad, la seguridad y el rendimiento que se espera.

Lo que se necesita es un enfoque para las pruebas de microservicios que permita el descubrimiento, la creación y la automatización de pruebas de componentes. Las tecnologías habilitadoras son servidores proxy de mensajes y virtualización de servicios que están estrechamente integrados con un marco de prueba de API rico en características.

Los proxies de mensajes permiten registrar el tráfico de API, monitorear para descubrir escenarios y casos de uso, y controlar para administrar y automatizar conjuntos de pruebas de API. Junto con la virtualización de servicios, las pruebas automatizadas de microservicios se convierten en una realidad alcanzable.