¿Por qué Threat Stack automatiza las pruebas de microservicios mediante contenedores?

Los microservicios, incluso cuando están diseñados correctamente, pueden resultar difíciles de probar. Pero cuando la arquitectura del sistema evoluciona hasta el punto en que decenas o cientos de servicios conectados conforman una plataforma de software en una infraestructura en constante cambio, entonces probar el producto del cual usted y su equipo son responsables se convierte en una tarea monumentalmente compleja. Escribir automatización de pruebas para estos entornos es difícil, por lo que conviene asegurarse de obtener el máximo valor de las pruebas que escribe.

En Threat Stack, escribimos pruebas de integración de sistemas, una forma de prueba funcional de caja gris, y elegimos Docker para ejecutar el entorno de prueba en contenedores.

¿Qué tienen de malo otros tipos de pruebas?

Algunas organizaciones aún dependen del modelo de pruebas tradicional, en el que las pruebas de caja blanca y caja negra se consideran una estrategia de pruebas complementaria suficiente. Si bien todavía juegan un papel importante en la calificación del software, ya no son suficientes para brindarle la retroalimentación que necesita para lanzar software con confianza.

En este tipo de entorno, las pruebas de aceptación de usuarios de caja negra están demasiado enfocadas y confiar en ellas puede tener serias implicaciones en las estrategias de tiempo de comercialización:

• No proporciona una cobertura adecuada, ya que hay demasiados escenarios posibles para probar en el tiempo asignado para ejecutar las pruebas.
• Se ejecuta durante largos períodos de tiempo y a menudo puede caducar debido a factores que escapan al control de la aplicación.
• Debe ejecutarse después de implementar el servicio, en lugar de en el momento de la compilación, lo que significa que la retroalimentación está más separada del desarrollo del producto. En la filosofía de desplazamiento a la izquierda que domina la ingeniería de pruebas, confiar en estas pruebas hace que su organización sea menos competitiva.
• Debido a que son pruebas de caja negra, determinar la causa de las fallas puede ser una tarea increíblemente difícil.
• No son fáciles de escribir ni de mantener para los desarrolladores.

Por otro lado, las pruebas unitarias de caja blanca tienen un enfoque demasiado estrecho y a menudo se utilizan incorrectamente para calificar la funcionalidad del sistema de software:

• No tiene en cuenta el comportamiento real de los servicios que interactúan con componentes u otros servicios.
• Puede probar escenarios sin sentido que no son lo suficientemente valiosos para mantenerlos.
• Puede resultar oneroso para los desarrolladores que tienen que actualizar continuamente grandes colecciones de pruebas para realizar pequeños cambios en el código.
• No es fácil de escribir ni de mantener para los ingenieros de pruebas.

¿Por qué centrarse en las pruebas de integración de sistemas?

Los ingenieros de pruebas de Threat Stack confían cada vez más en las pruebas de integración de sistemas para probar todos estos servicios de una manera que maximice la cobertura de la prueba y al mismo tiempo proporcione la velocidad y la especificidad que necesitamos para garantizar que la aplicação se comportará correctamente en muchas condiciones operativas.

Una prueba de integración es una prueba de caja gris que se centra en el comportamiento del software o sistema bajo prueba al interactuar con componentes externos. Por ejemplo:

• Un almacén de datos, por ejemplo, PostgreSQL, Cassandra, ElasticSearch
• Un intermediario de mensajes, por ejemplo, Kafka
• Un servidor HTTP

En otras palabras, un software con el que puedes interactuar para validar el comportamiento. En Threat Stack, ejecutamos principalmente pruebas funcionales que replican situaciones reales, pero los comportamientos bajo prueba se detendrán en los límites del entorno contenedorizado, evitando interacciones externas no deseadas.

Y como estas pruebas están estrechamente relacionadas con el microservicio, usted tiene el beneficio de examinar e integrar el código del servicio bajo prueba en las pruebas automatizadas para identificar consistentemente áreas del código a ejercitar. Además, estas pruebas se pueden escribir como pruebas de aceptación del usuario para que los no desarrolladores, como los gerentes de producto y los ingenieros de control de calidad, puedan comprender más fácilmente el comportamiento bajo prueba.

En otras palabras:

Dado un conjunto de algunas condiciones

Cuando el servicio recibe esta entrada (O esta condición afecta al servicio)

Entonces el servicio se comporta de la manera esperada y produce los efectos secundarios esperados.

Estas pruebas funcionales no solo son fáciles de entender y escribir, sino que también están estrechamente relacionadas con el código del microservicio, por lo que los desarrolladores pueden ejecutarlas y actualizarlas fácilmente durante el proceso de desarrollo o posteriormente por ingenieros de pruebas dedicados.

¿Por qué utilizar contenedores?

Los contenedores son extremadamente útiles para los sistemas de prueba ya que le permiten reproducir rápidamente su entorno de prueba con recursos mínimos mientras duran las pruebas y luego limpiarlo fácilmente cuando las pruebas terminan de ejecutarse. A diferencia de muchas automatizaciones de pruebas de caja negra, no necesita un entorno de prueba costoso y siempre activo para llevar a cabo sus pruebas de integración. Al ejecutar las pruebas, el comportamiento del microservicio se puede reproducir en el entorno de prueba. 

Una vez que define un entorno en contenedores que refleja el entorno del microservicio en producción, su marco de prueba se convierte en los clientes externos o servicios simulados que interactúan con los componentes o el microservicio bajo prueba. Esto garantiza que el código de prueba controle todos los aspectos de las pruebas, lo que le permite controlar muchos más aspectos de las pruebas.

Al comenzar, Docker es una buena plataforma para crear rápidamente un entorno en contenedores. Con Docker Compose , puedes definir y ejecutar fácilmente las secciones de tu aplicação bajo prueba, ya sea localmente o en CI usando el mismo código. También se pueden usar otras herramientas y servicios de infraestructura de contenedores, como Kubernetes , AWS EKS o AWS Fargate , para implementar su entorno de prueba si su organización admite su uso.

CONCLUSIÓN

En última instancia, la decisión de centrar los esfuerzos de prueba en las pruebas de integración en lugar de otros tipos de automatización le brinda dos grandes beneficios:

• Las pruebas de microservicios se desplazan a la izquierda para que se ejecuten antes de la implementación, lo que le brinda una respuesta más rápida para el desarrollo iterativo.
• Aún se ejecutan pruebas contra servicios y componentes reales, lo que significa que se reducen las brechas de cobertura de pruebas pero se siguen ejecutando pruebas funcionales.