Pruebas de integración encantadoras con Testcontainers

Hola. Estás viendo TestJS Summit y estas son pruebas de integración encantadoras con Test Containers. Testing es muy importante. Más proyectos deberían probar las aplicaciones mejor y espero que después de esta breve sesión, aprendas cómo puedes hacer pruebas de integración que te gusten usando las bibliotecas de Test Containers.

Mi nombre es Alex Shoive y trabajo como una persona de Relaciones con Desarrolladores en Atomic Jar, una empresa creada... una startup creada por los mantenedores originales de Test Containers en Java y ahora tenemos más personas de diferentes ecosistemas de lenguajes que nos ayudan a trabajar en Test Containers. Si tienes alguna pregunta, puedes encontrarme en línea. Estaré encantado de charlar sobre cualquier cosa. Test Containers, así que testing relacionado o simplemente ingeniería de software en general. Creo que sería muy, muy genial. Así que envíame, envíame un mensaje.

Testing es súper, súper importante porque se encuentra en los caminos críticos desde el desarrollo hasta la producción. Si no tenemos un buen conjunto de pruebas automatizadas, no podemos liberar cosas bien. Necesitamos tener pruebas automatizadas porque queremos asegurarnos de que siempre que tengamos algo que potencialmente queramos liberar, podemos pasar por nuestro pipeline sin cuellos de botella en ningún proceso manual. Esto es útil durante una práctica de desarrollo normal, ciclo de desarrollo, pero también es súper útil en caso de que haya problemas de seguridad o problemas de cadena de suministro de seguridad donde actualizas los paquetes de terceros, y luego necesitas liberar cosas porque podrían ser problemas de seguridad y vulnerabilidades, pero si no tienes buenos conjuntos de pruebas en los que confíes, entonces este es un proceso manual y estás tan expuesto como siempre. Pero si lo haces, puedes ejecutar tus pruebas automatizadas. Puedes liberar inmediatamente porque tienes confianza en tus pruebas. Esto es muy, muy importante, y últimamente, la forma en que vemos qué tipos de pruebas queremos ejecutar ha cambiado.

En el pasado, teníamos la pirámide de testing y ejecutábamos un montón de unit tests y cubrían todos los escenarios posibles y teníamos una muy buena cobertura de pruebas, y aún así nos perdimos algunos problemas. Así que, recientemente, equipos independientes han estado saliendo a la luz sobre cómo están repensando la pirámide de testing y cómo ponen más y más énfasis en las pruebas de integración. Mientras tanto, tiene mucho sentido. Nuestras aplicaciones se han vuelto más pequeñas. Estamos escribiendo en su mayoría, y estamos hablando de las aplicaciones de backend aquí, estamos escribiendo principalmente microservices que hablan con otras APIs o hablan con varias tecnologías como bases de datos o intermediarios de mensajes o tecnologías de Cloud, y el comportamiento de la aplicación está muy codificado en las interacciones con esos sistemas de terceros más que en la lógica de negocio dentro de la aplicación particular, cómo transforma los data. Por lo tanto, tiene sentido tener menos pruebas de detalles de implementación, y usar la prueba de integración que ejecuta tu aplicación con el entorno inmediato, con todos los componentes necesarios para que tu aplicación funcione correctamente como lo haría en producción, pero en tu configuración de testing. Eso podría ser la mayor parte de nuestro conjunto de pruebas. Esa podría ser la prueba en la que confiamos y en la que nos apoyamos. Y todavía podemos tener pruebas de integración de extremo a extremo que se ejecutan en un entorno similar a la producción, donde todos los sistemas se activan al mismo tiempo. Y cuando verificamos los flujos de trabajo reales, como si fuera un entorno de producción, data de producción, o data similar, pero en un entorno mucho más grande. Así que para un conjunto de pruebas que ejecutas en todas partes, en tu máquina, en la máquina de tu colega, en tu CI, las pruebas de integración dan en el punto dulce entre la simplicidad de la configuración y también cuántos problemas con las tecnologías del mundo real pueden detectar. Por eso están ganando más y más popularidad.

Esto nos lleva a Test containers. Test containers son bibliotecas en diferentes lenguajes, incluyendo la implementación de test getters' node que funciona para JavaScript y TypeScript. Se integran con Docker para crear entornos efímeros donde puedes ejecutar las dependencias de servicios de terceros que tu aplicación requiere. Puedes ejecutar las bases de datos, puedes ejecutar tu Kafka, puedes ejecutar tu Elasticsearch, puedes aprender tu local stack, si trabajas con tecnologías LWS.

Puedes ejecutarlos en Docker containers, y tu aplicación tiene el control total sobre el ciclo de vida de estos. Y tus pruebas tienen el control total sobre la configuración de estos. Así que puedes probar tu aplicación con las dependencias reales y saber que funciona como se espera.

Test containers ha sido recientemente nombrado en el Radar de Tecnología de ThoughtWorks. Fue puesto en la categoría Adulto, lo que significa técnicamente que debería haber una fuerte razón. Realmente deberías saber lo que estás haciendo, si no quieres usar Test containers. Test containers te permite crear un entorno confiable con la creación programática de esos containers ligeros para tus dependencias. Y hace tus pruebas más confiables, e intenta empujarte a hacer las cosas correctas con tus pruebas de integración, y por eso hay cada vez más proyectos, que están utilizando Test containers en diversas configuraciones y entornos.

Test containers utiliza Docker como el entorno donde inicia esos containers que tu aplicación quiere ejecutar. Y esto es genial porque Docker está casi universalmente disponible, funciona en todos los sistemas operativos populares, y sus desarrolladores entienden cómo funciona Docker, o cómo usar Docker desde el exterior. Así que esta es una gran opción para aprovechar un tiempo de ejecución para ejecutar esas dependencias para tu aplicación. Sin embargo, el aspecto y la sensación de Docker no son a veces lo suficientemente flexibles para tus pruebas de integración.

Docker es genial porque tiene todo el software del mundo que puede ser ejecutado en Docker. Hay registros donde puedes obtener todas las tecnologías que tu alma requiere. Te proporciona aislamiento de procesos. Te proporciona la capacidad de configurar tanto el contenedor como la aplicación dentro del contenedor. Te dan los límites de CPU y memoria. Todas esas cosas buenas, pero es un poco inflexible para las pruebas específicamente porque durante las pruebas, queremos poner nuestra aplicación en escenarios específicos donde algo podría salir mal. ¿Qué sucederá cuando la aplicación trabaje con una database y el esquema de data sea incorrecto? ¿O qué sucederá si mi aplicación no tiene una latencia larga hasta que llegue a Kafka? ¿O qué sucede cuando los números de clave de mi Redis están cerca del rango de enteros y están tratando de desbordarse? Todos los diferentes escenarios y todos rompen la configuración de alguna manera. Esta es la noción de pruebas. Esto es lo que las pruebas deberían hacer. Ponen tu aplicación bajo estrés y luego quieren averiguar si se comporta correctamente. Así que con Docker, una vez que rompes el entorno, es muy, muy difícil recrear el entorno. Y aquí es donde entra TestContainers.

TestContainers te da acceso programático para crear, administrar, ciclo de vida y limpiar los containers que quieres ejecutar. Te da una API para configurar tanto el contenedor, como exponer qué puertos quieres exponer desde el contenedor si estás trabajando con él a través de la red.

O qué archivos quieres copiar, o si quieres seguir programáticamente los registros del contenedor y así sucesivamente. Así que puedes configurar todo desde tus pruebas de aplicación, desde tu IDE. Y no necesitas, puedes, puedes hacer esto cualquier número de veces. Así que las pruebas traen su propio entorno al juego. Y también se integra con varios frameworks y bibliotecas de pruebas.

Por ejemplo, hay un módulo para Jest test containers, que simplifica el trabajo con Jest test, y test containers, donde puedes especificar declarativamente qué containers quieres, por ejemplo. Testcontainersnode, como las otras implementaciones de test containers, es un proyecto de código abierto. Christian es un verdadero héroe de la implementación de testcontainersnode, el principal mantenedor actualmente. Hay un paquete npm, que es cómo obtienes test containers en tu aplicación. Y lo que hace, utiliza docker-node para hablar con el entorno docker, así que tu entorno docker no necesita ser ninguna implementación docker en particular. Por supuesto, funciona con Docker Desktop, pero también puede funcionar con cualquier otra implementación docker compatible. Así que, por ejemplo, si estás ejecutando Minikube, el ligero clúster de Kubernetes que expone la API de Docker, puedes usar eso para ejecutar tus pruebas basadas en test containers. O si estás usando un Docker remoto, tus test containers pueden hablar con eso. Y internamente en Atomic Jar, estamos construyendo la solución cloud, donde puedes obtener una VM bajo demanda y ejecutar tus pruebas de test containers contra eso. Así que es una configuración muy, muy flexible, y funciona realmente bien.

Una cosa que es muy importante aquí es que test containers se encarga de la limpieza de los containers. Sabemos que para pruebas de integración confiables, necesitas tener un entorno repetible, y para eso, siempre quieres limpiar después de la ejecución. Eso significa que si tus pruebas pasan, limpiamos los containers y los eliminamos. Si tus pruebas fallan, limpiamos los containers y los eliminamos. Si tu máquina funciona con un entorno Docker remoto y tu máquina se bloquea, como si Internet explotara, todavía limpiaremos los containers en el host Docker remoto. Eso significa que nunca estarás en una situación en la que tu prueba se conecte a la instancia de Kafka que iniciaste hace dos semanas y que por alguna razón está persistiendo en tu potente máquina CI. Y luego porque los problemas que surgen de eso son realmente, realmente difíciles de reproducir e increíblemente difíciles de debug y arreglar. Así que las bibliotecas de test containers intentan empujarte en la dirección correcta con las pruebas de contenedores de prueba para permitir la paralelización de las pruebas de manera agradable, para empujarte a usar la API correcta, para hacer la limpieza en todo momento. Y en general, es un enfoque muy, muy popular.

Además de ser una buena biblioteca por sí misma, test containers viene con un ecosystem de los modules donde las tecnologías populares tienen una pequeña implementación, pequeñas bibliotecas, pequeños modules, que especifican y codifican cómo ejecutar esa tecnología particular en tu code. Así que no tienes que averiguar qué necesitas hacer para ejecutar Cassandra en un contenedor Docker o Kafka en un contenedor Docker, pero puedes simplemente usar la API y especificar, dame un contenedor Kafka, dame un contenedor MongoDB, y obtendrás una instancia de eso inmediatamente para ti, lo cual es genial porque eso te permite concentrarte en la lógica de negocio real de tus tareas sin gastar tiempo en averiguar la infraestructura, porque eso es gestionado por task containers. Y no es sólo un proyecto de nodo, ¿verdad? Task containers es bueno las pruebas de integración son necesarias en cualquier ecosystem de cualquier lenguaje de programación. Así que lo que puedes hacer, puedes tener el enfoque similar en tu aplicación Java, en tus aplicaciones .NET, en tu aplicación Go, hay Python, hay task containers Rust. Así que es un enfoque de ingeniería muy, muy popular. Y ahora me gustaría mostrarte un poco cómo se siente tener tareas y cuáles son los bloques de construcción de la API que necesitas conocer para ser productivo con task containers.

Vamos a explorar el IDE. Bien. Así que tengo un proyecto muy, muy simple aquí. No tiene ni siquiera la aplicación real. Solo quiero darles una idea de la API y hablar de lo que es importante desde el punto de vista de task containers.

Muy bien. Así que podemos declarar la dependencia como de costumbre para obtener ese paquete npm. Y aquí en nuestro archivo de prueba, lo que podemos hacer, podemos requerir task containers y el bloque de construcción básico es el contenedor genérico. El contenedor genérico es una abstracción que representa el contenedor que podemos gestionar a través de task containers. Lo que necesitamos darle, necesitamos darle el nombre de la imagen Docker, que es en los casos actuales, Redis vamos a ejecutar con el contenedor Redis y luego hacemos la configuración. Podemos exponer los puertos. Podemos configurar qué archivos necesitamos copiar en el contenedor. Por ejemplo, esta es una buena manera de instanciar tu esquema de database enviándolo a tu contenedor. Y luego, por supuesto, tenemos los métodos para usar y configurar el ciclo de vida de nuestros containers de nuestra infraestructura que necesitamos para la prueba.

Así que aquí en esta prueba, estamos. Especificamos que queremos crear el contenedor antes de todas las pruebas. Así que este contenedor será compartido entre todas las pruebas. Actualmente, no tenemos muchas, pero creamos el contenedor y luego esto es lo interesante, el contenedor puede ser ejecutado en cualquier lugar. Puede estar ejecutándose en el host Docker remoto o en tu host local o en una VM en algún lugar. Cuando nos aseguramos de que nuestra aplicación sabe cómo hablar con la tecnología, con la database, o en este caso, Redis en ese contenedor, no codificamos ninguna configuración, pero usamos esa instancia de contenedor genérico para proporcionar información de dónde se está ejecutando para que podamos configurar nuestra aplicación correctamente. Así que aquí simplemente decimos, oh Redis, vas a hablar con Redis, el cliente Redis, lo siento. Vas a hablar con Redis por ese host, que obtenemos del contenedor y el puerto expuesto 6379 será mapeado al puerto aleatorio de alto nivel en el lado del host aquí. Digamos, obtenemos el puerto mapeado para ese valor, y luego nuestro cliente Redis está listo para conectarse a Redis. Después de todo, limpiamos todo, pero no tenemos que hacerlo. Al menos no tenemos que limpiar el contenedor porque test containers, cuando nuestras pruebas pasan, test containers lo limpiará por sí mismo. Pero esta es aún una buena práctica, si quieres desplegar miles de containers durante una suite de pruebas, tal vez deberías cuidar del ciclo de vida tú mismo y detenerlos. Así que simplemente no usan todos los recursos al mismo tiempo. Así que la prueba en sí misma es súper simple. Solo queremos poner los valores en Redis y obtener los valores en Redis. Y puedes ver que si ejecuto mi aplicación, entonces podemos ver que los containers están allí.

Entonces, si hago docker stats. Actualmente solo está el contenedor raíz, que es el contenedor testing que usa internamente para limpiar con fines de limpieza. Entonces, si solo hago. Configuración muy simple aquí. Así que volveré a ejecutar las pruebas y puedes ver que los containers se activarán por un segundo y luego también se ejecutarán.

Entonces, no ejecuto mi Docker localmente aquí. Utilizo la cloud de TestCenter, que está conectada a un clúster cercano. Ahí es donde se ejecutan mis containers Docker. Y luego, si quieres un ejemplo más grande de nuestra situación, entonces tengo uno diferente. Esta es una aplicación express real que utiliza MongoDB como almacenamiento. Permíteme solo la prueba muy simple. Veamos la prueba. Solo usamos SuperTest para enviar una solicitud, pruebas funcionales de alto nivel reales para nuestra aplicación. Y luego esperamos que esas solicitudes tengan éxito. Y luego esperamos los data de vuelta. Entonces, esta es una prueba funcional de muy alto nivel.

Y la parte interesante aquí es que no construimos los containers nosotros mismos. No decimos cómo configurar MongoDB. Pero lo que estamos haciendo, solo estamos importando el módulo que podemos tener. Y si miras el... Si miras el repositorio, puedes ver que hay algunos modules que son para tecnologías bastante comunes. MySQL, Mongo, Kafka, Elasticsearch, Postgres que están ahí. Y no es una implementación tan grande. Entonces, si estás interesado en cualquier otra tecnología que quieras ejecutar, tal vez después de averiguarlo para tu entorno, considera contribuir con un módulo de vuelta. Eso sería un gran uso. Correcto. Entonces aquí usamos Mongo. Y puedes ver cómo funciona. Entonces, una forma de ser contenedor que ejecutamos.

Así que ahora después de eso, por supuesto, nos desconectamos y luego podemos ejecutar las pruebas. Y aquí ejecutamos más pruebas. Así que si ejecuto NPM test aquí, puedes ver en segundo plano, si la imagen de Docker no está en la caché de mi demonio de Docker, entonces la imagen será automáticamente extraída del Hub de Docker para soporte de Escritorio, los registros privados también, authentication, cualquier cosa que puedas extraer con Docker sería soportada. Y luego puedes simplemente ejecutarlo. Y luego después de que todo está dicho y hecho, los containers se limpian y se eliminan junto con los volúmenes y todo eso. Así que es un enfoque muy, muy flexible. Es muy fácil de integrar en tus aplicaciones. También puedes empaquetar tu aplicación en un contenedor de Docker, pero yo preferiría ejecutarlo normalmente, ejecutarlo normalmente en mi máquina para mi ID, porque entonces pueden enviar puntos de interrupción y ejecutarlo a voluntad.

Así que solo una diapositiva más. Hay que puedes hacer las cosas complejas. Puedes construir topologías complejas con red. Puedes esperar a que la database en el contenedor se inicie. Puedes crear las imágenes al vuelo. Puedes extraer los registros y copiar archivos de ida y vuelta y ejecutar los comandos. Cualquier cosa que funcione con Docker funciona como test containers. Y creo que este es un enfoque realmente, realmente genial. Y eres bienvenido a consultar la fuente en GitHub. Y si tienes alguna pregunta o si quieres probar y hablar con la community, por favor únete a Slack en SlackTaskContainers.org para hablar con personas de ideas afines. Eso es todo. Muchas gracias por ver. Y si tienes alguna pregunta, estaré encantado de responderla. Gracias.