Estas son las estrategias de prueba de microservicios más efectivas, según los expertos

Probar microservicios es difícil. Más específicamente, las pruebas de un extremo a otro son difíciles, y eso es algo que discutiremos con más detalle en este artículo.

Pero primero, una breve historia.

Aprendí cuán difíciles pueden ser las pruebas de microservicios cuando me sumergí por primera vez en una pila de tecnología con siete microservicios separados. Cada uno tenía su propia base de código, gestión de dependencias, ramas de funciones y esquema de base de datos, que también tenía un conjunto único de migraciones.

Habla de agitado.

El enfoque que adoptamos fue ejecutar todo localmente. Eso significaba que, en cualquier momento dado en el que quisiera ejecutar pruebas de un extremo a otro, tendría que seguir los siguientes cinco pasos para cada uno de los siete microservicios:

  1. Asegúrate de estar en la rama de código correcta (ya sea master o feature_xyz)
  2. Baje el código más reciente para esa rama
  3. Asegúrese de que todas las dependencias estén actualizadas
  4. Ejecute cualquier nueva migración de base de datos
  5. Iniciar el servicio

Este era solo un requisito básico para permitir la ejecución de pruebas. A menudo, me olvido de realizar uno de estos pasos para un servicio y dedico de 10 a 15 minutos a depurar el problema. Una vez que finalmente tuve todos los servicios felices y funcionando, pude comenzar a poner en marcha la suite de pruebas. Esta experiencia me hizo perderme los días de probar un gran monolito.

Entonces, sí, descubrí que las pruebas de microservicios de un extremo a otro son difíciles y se vuelven exponencialmente más difíciles con cada nuevo servicio que presenta. Pero no temas, porque hay formas de facilitar las pruebas de microservicios. He hablado con varios CTO sobre cómo idearon sus propias formas creativas de abordar este complejo problema.

Métodos comunes de prueba de microservicios

Examen de la unidad

Un microservicio puede ser más pequeño por definición, pero con las pruebas unitarias, puede ser aún más granular. Una prueba unitaria se centra en la parte más pequeña de un software comprobable para determinar si ese componente funciona como debería. El reconocido ingeniero de software, autor y orador internacional Martin Fowler divide las pruebas unitarias en dos categorías:

  1. Prueba de unidad sociable: este método de prueba de unidad prueba el comportamiento de los módulos al observar cambios en su estado.
  2. Prueba de unidad solitaria: este método se centra en las interacciones y colaboraciones entre un objeto y sus dependencias, que se reemplazan por dobles de prueba.

Si bien estas estrategias de prueba unitaria son distintas, Fowler afirma que no compiten, se pueden usar en conjunto para resolver diferentes problemas de prueba.

Durante una discusión con David Strauss, CTO de Pantheon, David me dijo que "la oportunidad es que los microservicios son muy sencillos de realizar pruebas unitarias".

Pruebas de integración

Con las pruebas de integración, está haciendo lo que parece que está haciendo: probar las rutas de comunicación y las interacciones entre los componentes para detectar problemas. Según Fowler, una prueba de integración "ejercita las rutas de comunicación a través del subsistema para verificar si hay suposiciones incorrectas que cada módulo tiene sobre cómo interactuar con sus pares".

Una prueba de integración generalmente prueba las interacciones entre el microservicio y los servicios externos, como otro microservicio o almacén de datos.

Pawel Ledwoń, líder de plataforma en Pusher, me informó que su equipo “se inclina [s] por las pruebas de integración. Las pruebas unitarias siguen siendo útiles para algunas abstracciones, pero para las funciones de cara al usuario es difícil burlarse de ellas o omitir partes importantes del sistema ".

No todos con los que hablé eran fanáticos del proceso. La opinión de Mosquera sobre el tema de las pruebas de integración, por ejemplo, vale la pena señalar:

Las pruebas de integración son muy propensas a errores y costosas, en términos de horas de trabajo. El ROI simplemente no existe. Cada prueba de integración individual aporta una pequeña cobertura marginal de casos de uso.

Prueba de extremo a extremo

Por último, pero no menos importante, están las pruebas de extremo a extremo, que, como se mencionó anteriormente, pueden ser una tarea difícil. Eso es porque implica probar cada parte móvil del microservicio, asegurando que pueda alcanzar los objetivos para los que lo creó.

Fowler escribió lo siguiente:

Las pruebas de extremo a extremo también pueden tener en cuenta la asincronía en el sistema, ya sea en la GUI o debido a procesos de backend asincrónicos entre los servicios.

Continúa explicando cómo estos factores pueden resultar en "escamas, tiempo de ejecución de prueba excesivo y costo adicional de mantenimiento del conjunto de pruebas".

El mejor consejo que puedo dar cuando se trata de pruebas de un extremo a otro es limitar la cantidad de veces que lo intentas por servicio. Un equilibrio saludable entre las otras estrategias de prueba de microservicios mencionadas, como las pruebas unitarias y las pruebas de integración, lo ayudará a eliminar problemas más pequeños.

Una prueba de extremo a extremo es más grande por definición, lleva más tiempo y puede ser mucho más fácil equivocarse. Para mantener sus costos bajos y evitar pérdidas de tiempo, apéguese a las pruebas de extremo a extremo cuando se hayan agotado todos los demás medios de prueba y como sello final de garantía de calidad.

Los desafíos de probar microservicios

Los microservicios (en comparación con un monolito) requieren pasos adicionales, como administrar múltiples repositorios y ramas, cada uno con sus propios esquemas de base de datos. Pero los desafíos pueden ser más profundos que eso.

A continuación, se muestran algunos desafíos clave asociados con las pruebas de microservicios:

  • Disponibilidad: dado que diferentes equipos pueden estar administrando sus propios microservicios, asegurar la disponibilidad de un microservicio (o, peor aún, tratar de encontrar un momento en el que todos los microservicios estén disponibles a la vez), es difícil.
  • Pruebas fragmentadas y holísticas: los microservicios están diseñados para funcionar solos y junto con otros servicios poco acoplados. Eso significa que los desarrolladores deben probar cada componente de forma aislada, así como probar todo junto.
  • Brechas de conocimiento: particularmente con las pruebas de integración (que abordaremos más adelante en este artículo), quien realice las pruebas deberá tener un conocimiento sólido de cada servicio para poder escribir casos de prueba de manera efectiva.

Según Oleksiy Kovyrin, director de Swiftype SRE en Elastic,

Un tema importante que debemos tener en cuenta al trabajar con microservicios es la estabilidad de la API y el control de versiones de la API. Para evitar romper aplicaciones dependiendo de un servicio, debemos asegurarnos de tener un conjunto sólido de pruebas de integración para las API de microservicio y, en caso de un cambio importante, debemos proporcionar una forma compatible con versiones anteriores para que los clientes migren a una nueva versión a su propio ritmo para evitar grandes implementaciones de cambios de API entre servicios.

Stefan Zier, arquitecto jefe de Sumo Logic, también me reiteró que las pruebas de microservicios son realmente "muy, muy difíciles".

“Especialmente una vez que se avanza hacia un despliegue más continuo. Hemos invertido y seguimos invirtiendo bastante en pruebas de integración, pruebas unitarias, y haríamos mucho más si tuviéramos la gente para hacerlo ”, me dijo Zier.

Dicho esto, admitió que, en ciertas etapas, cuando Sumo Logic quiere probar sus servicios de manera integral, "más o menos [toda la empresa [se convierte] en un equipo de garantía de calidad en cierto sentido".

Solución: cinco estrategias de prueba de microservicios para startups

Sí, probar microservicios puede ser difícil, pero dados todos los beneficios de los microservicios, renunciar a ellos debido a desafíos de prueba no es el camino correcto. Para abordar estos desafíos, obtuve información de varios CTO y destilé cinco estrategias que usaron para abordar con éxito las pruebas de microservicios.

1. La estrategia de documentación primero

Chris McFadden, vicepresidente de Engineering Sparkpost, resumió muy bien la estrategia de documentación primero durante nuestra discusión:

Seguimos un primer enfoque de documentación para que toda nuestra documentación esté rebajada en GitHub. Nuestros documentos de API son de código abierto, por lo que todos son públicos. Luego, lo que haremos es antes de que alguien escriba cambios en la API o en una nueva API o cambios en una API, primero actualizarán la documentación, revisarán ese cambio para asegurarnos de que cumpla con nuestras convenciones y estándares de API, que son todo documentado y asegúrese de que no se introduzcan cambios importantes aquí. Asegúrese de que cumpla con nuestras convenciones de nomenclatura y demás.

Si está dispuesto a dar un paso más, podría incursionar en las pruebas de contrato de API, que, como se mencionó anteriormente, implica escribir y ejecutar pruebas que garanticen que el contrato explícito e implícito de un microservicio funcione como debería.

2. La estrategia de pila completa en una caja

La estrategia de pila completa en una caja implica replicar un entorno de nube localmente y probar todo en una instancia de vagabundo ("$ vagrant up"). ¿El problema? Es extremadamente complicado, como explicó la ingeniera de software Cindy Sridharan de Imgix en una publicación de blog:

He tenido experiencia de primera mano con esta falacia en una empresa anterior en la que trabajé, donde tratamos de hacer girar toda nuestra pila en una caja vagabunda [local]. La idea, como puede imaginar, era que un simple vagabundo debería permitir a cualquier ingeniero de la empresa (incluso a los desarrolladores frontend y móviles) poder hacer girar la pila en su totalidad en sus computadoras portátiles.

Sridharan continúa detallando cómo la empresa solo tenía dos microservicios, un servidor API basado en gevent y algunos trabajadores en segundo plano de Python asincrónicos. Una configuración relativamente simple, por supuesto.

“Recuerdo haber pasado toda mi primera semana en esta empresa tratando de poner en marcha con éxito la VM localmente solo para encontrarme con una plétora de errores. Finalmente, alrededor de las 4:00 pm del viernes de mi primera semana, logré que la configuración de Vagrant funcionara y todas las pruebas pasaron localmente. Recuerdo que me sentí increíblemente agotada ”, narró.

Además, Stefan Zier, arquitecto jefe de Sumo Logic, me explicó que, además de ser difícil de llevar a cabo, esta estrategia de pruebas localizadas simplemente no escala:

“[Con] una implementación local, ejecutamos la mayoría de los servicios allí para que usted obtenga un sistema en pleno funcionamiento y eso ahora se extiende incluso a las máquinas de 16 GB de RAM bastante. Así que eso realmente no escala ”, dijo.

3. La estrategia de prueba de AWS

Esta tercera estrategia implica poner en marcha una infraestructura de Amazon Web Services (AWS) para que cada ingeniero la implemente y ejecute pruebas. Este es un enfoque más escalable para la estrategia de pila completa en una caja discutida anteriormente.

Zier llamó a esto una "[estrategia] de implementación personal, en la que todos aquí tienen su propia cuenta de AWS".

“Puede enviar el código que está en su computadora portátil a AWS en unos diez minutos y ejecutarlo como un sistema real”, dijo.

4. La estrategia de instancias de prueba compartidas

Me gusta pensar en esta cuarta estrategia como un híbrido entre la pila completa en una caja y las pruebas de AWS. Esto se debe a que involucra a los desarrolladores que trabajan desde su propia estación local, mientras aprovechan una instancia compartida separada de un microservicio para apuntar su entorno local durante las pruebas.

Steven Czerwinski, director de ingeniería de Scaylr, explicó cómo esto puede funcionar en la práctica:

Algunos de [nuestros] desarrolladores ejecutan una instancia separada de un microservicio solo para usarla para probar compilaciones locales. Así que imagina que eres un desarrollador, estás desarrollando en tu estación de trabajo local y no tienes una forma fácil de iniciar el analizador de imágenes. Sin embargo, su constructor local solo apuntaría a un analizador de imágenes de prueba que se ejecuta en la infraestructura de Google.

5. La estrategia de servicios interrumpidos

Y finalmente, tenemos la estrategia de prueba de servicios stubbed.

Zier expuso el enfoque de SumoLogic para las pruebas de servicio stubped diciéndome cómo, "stubbing le permite escribir estas marcas o 'stubs' de microservicios que se comportan como si fueran el servicio correcto y se anuncian en nuestro descubrimiento de servicios como si fueran un servicio real , pero son solo una imitación ficticia ”, explicó.

Por ejemplo, probar un servicio puede requerir que el servicio se dé cuenta de que un usuario lleva a cabo un conjunto de tareas. Con los servicios stubbed, puede pretender que el usuario (y sus tareas) se han llevado a cabo sin las complejidades habituales que conlleva. Este enfoque es mucho más ligero en comparación con los servicios en ejecución en su totalidad.

Herramientas para ayudarlo a probar microservicios

Aquí hay una lista de herramientas que me han beneficiado durante mis propias experiencias de prueba de microservicios, reforzadas por algunas recomendaciones del grupo de CTO y desarrolladores senior:

  • Hoverfly: simula latencia y fallas de API.
  • Vagrant: cree y mantenga entornos portátiles de desarrollo de software virtual
  • VCR: una herramienta de prueba unitaria
  • Pacto: marcos de pruebas de contratos impulsados ​​por el consumidor.
  • Colmenar: herramienta de documentación API
  • API Blueprint: diseño y prototipos de API
  • Swagger: diseño y prototipos de API

Prueba de microservicios: difícil, pero vale la pena

Probar sus microservicios no será un paseo por el parque, pero el trabajo adicional vale los beneficios de tener una arquitectura de microservicios.

Además, las estrategias de prueba de microservicios adoptadas por empresas como SumoLogic y Scaylr deberían ayudar a suavizar el proceso. Aquí hay un resumen rápido de esas estrategias:

  1. La estrategia de documentación primero
  2. La estrategia de pila completa en una caja
  3. La estrategia de pruebas de AWS
  4. La estrategia de instancias de prueba compartidas
  5. La estrategia de servicio cortada

Naturalmente, es posible que deba modificar cada estrategia para que coincida con sus circunstancias únicas, pero con un buen ensayo y error a la antigua, su estrategia de prueba de microservicio debería funcionar.

Si te ha gustado este artículo, ¡ayúdalo a difundir aplaudiendo! Para obtener más contenido como este, síganos en Twitter y suscríbase a nuestro blog.

Jake Lumetta es el CEO de ButterCMS y está publicando Microservices for Startups.

Y si desea agregar un blog o CMS a su sitio web sin perder el tiempo con Wordpress, debería probar Butter CMS.