Pruebas similares a producción en CI/CD con Testcontainers y Node.js

Hola, y bienvenidos a mi charla donde aprenderán cómo probar una aplicación Node.js en un entorno similar a producción usando Test Container. Así que, imagina esto. Estás desarrollando una característica. Escribes una prueba unitaria. Todo salió en verde. Lo subes a GitHub. Nos parece bien, y está listo para el mundo. Así que presionas el botón de despliegue, y está en vivo.

Contactas a tu gerente y dices, Oye, todo salió en verde. Desplegué esto. Pero de repente, recibes mensajes de Slack diciendo, Oye, algo pasó después de que desplegaste algo. La base de datos se cayó o está ocurriendo algún error. Así que estás en problemas tratando de encontrar qué está pasando. Entonces, miras los registros, y lo que ves es que tu servicio no se conectó a un servicio externo.

Así que, el problema aquí la mayoría de las veces es que nosotros, como ingenieros de software, ya no estamos escribiendo monolitos. Estamos escribiendo, la mayoría de las veces, microservicios o sistemas distribuidos, y somos solo una pequeña rueda dentada en un panorama mucho más grande, un sistema mucho más grande. Así que, por eso estos servicios que estamos escribiendo necesitan hablar con un servicio diferente o a través de una API o similar. Y eso a menudo, nosotros incluidos, resulta en que estamos descuidando las pruebas de integración. Sí, lo estamos probando usando pruebas unitarias, pero el panorama más grande, lo estamos descuidando. Así que, simular en este caso no es suficiente, porque, como dije, necesitamos hablar con diferentes servicios. Y, sí, eso nos ha pasado a todos. Y también me ha pasado a mí.

Entonces, ¿quién soy yo? Mi nombre es John. Soy un ingeniero de software en EON. EON es un proveedor de energía, enfocado en el mercado de Europa Occidental. Trabajo para una subsidiaria, que se enfoca en proporcionar soluciones digitales a nuestra empresa matriz, EON. Pero he estado trabajando en la web como desarrollador durante más de una década. Y siempre fui, siempre soy apasionado por las tecnologías web. Hice DevOps, soy parte de la comunidad de AWS con un programa, y estoy basado en Berlín. Y hay un dato curioso sobre mí. Me ducho con agua fría todos los días, sin importar el clima, a menos que esté enfermo, entonces me ducho a temperatura normal o no me ducho en absoluto.

Entonces, hacer pruebas de integración es difícil. Lo es. Lo hice en el pasado con, sí, desplegando en una cuenta sandbox y probándolo allí. Pero nunca refleja el mundo real. Y esto es lo que esta biblioteca test container quiere abordar. Envuelve servicios reales en el contenedor Docker, y te permite hacer pruebas de integración contra una base de datos real, un usuario de broker de mensajes, como Kafka o WebMQ. E incluso puedes probarlo contra servicios en la nube usando un local stack o cualquier tipo de entorno simulado. Test container te proporciona una infraestructura aislada, bajo demanda, que puedes usar localmente, pero también en tu pipeline CICD.

Por supuesto, el objetivo aquí es tener una mayor confianza al enviar tu aplicación. Entonces, lo que hace test container. Aún tienes que escribir tus pruebas, y se asegura de que inicie el contenedor por ti. En este caso, como ejemplo, tu base de datos Postgres. Y luego se asegura de que ejecute la prueba contra el contenedor, que test container te proporcionó. Y después de eso, elimina el contenedor. Así que, esto es test container en resumen. Pero sí, ¿cuál es la diferencia entre, pero ahora puedes decir, está bien, por qué no usamos Docker Compose aquí? Bueno, como ingeniero de software, estamos trabajando en varios proyectos, en varios servicios. Así que, en mi caso, tengo un proyecto antiguo, que todavía está ejecutándose en Postgres 8, creo.

Pero a veces sucede que también recibo un proyecto Greenfield, donde quiero usar lo último y lo mejor. Entonces, lo último es Postgres 16, creo. Pero ambas versiones de Postgres están usando el mismo pod. Así que están usando 5, 4, 3, 2, y esto resulta en un conflicto. Al escribir un archivo Docker Compose, también necesitas entender la red interna de Docker. Por supuesto, esto no es magia y es factible de aprender, pero es mejor tener algún tipo de abstracción.

Y siempre que ejecuto Docker Compose, siempre uso un flag de daemon. Eso significa que lo lanzo y me olvido. Y después de probar usando Docker Compose, siempre olvido eliminar el contenedor después. Y sí, los test containers facilitan o limpian automáticamente el contenedor Docker por ti. También es más fácil reemplazar un servicio adicional usando test container. Pero veámoslo en acción.

Entonces, tengo un pequeño proyecto bun aquí. Tengo dos funciones donde solo estoy usando el cliente bun Redis de internet. Y solo estoy estableciendo un valor de caché, una clave y obteniendo el valor usando la clave. También estoy pasando el cliente Redis. Entonces, en test container, estoy usando el módulo llamado Redis. Así que, vuelve. Entonces, los test containers también tienen como módulos donde puedes encontrar varios servicios, como bases de datos relacionales, como la base de datos Postgres, MySQL, o bases de datos NoSQL, Message Broker, como mencioné, Kafka, WebMQ. Y así también tienen el cliente Redis y está disponible en diferentes lenguajes, no solo Node.js, sino también en Python o Rust o Java.

Y lo que hice, entonces lo que hice fue simplemente instalar este módulo. Y ahora lo puse aquí. Y encontrarás dos variables aquí, el contenedor Redis y el contenedor Redis iniciado. Entonces, lo que el contenedor Redis necesita como argumento es la cadena de imagen. Entonces, cuando usas docker, o internamente usa docker, así que tienes que usar la imagen oficial de Redis docker. Y en este caso, estoy usando la versión 8. La versión 8 aquí. Y esto es también lo que puedes ver aquí.

Bien. Ahora, echa un vistazo a mi cliente docker. Así que estoy usando lazy docker aquí. Como puedes ver, no hay ningún contenedor ejecutándose ahora mismo. También tengo solo una imagen, que es el local stack. Y ahora, intentemos ejecutar esta prueba. Así que estoy ejecutando la prueba bunt. Y mi terminal pide usar como docker en este caso. Y lo que puedes ver aquí, entonces, o lo que hace en el fondo, ahora está poniendo la imagen, la imagen Redis 8, como puedes ver aquí. Y también está usando los test containers.

Así que toma nuestro código, lo pone en el contenedor. El contenedor ahora está ejecutándose. Y toma la prueba. Y luego, dentro de esta imagen real, realiza el test container contra el clúster Redis. Y como puedes ver ahora, está pasando. Correcto. Bien. Ahora, digamos, bien, tienes como requisito de negocio, el cambio de licencia de Redis. Así que ahora, realmente no es más de código abierto. Entonces, ¿hay una versión diferente de código abierto de Redis? La respuesta corta es sí, la hay. Así que hay algo llamado Walkie, que es como la versión de código abierto de Redis. Y también tienen un módulo Node.js para eso.

Entonces, instalemos eso. Así que, estoy usando uno aquí. Lo estoy agregando. Y ahora, en lugar de usar Redis aquí, estoy usando Walkie aquí. Y podría reemplazar fácilmente, así que podría reemplazar estos. Porque, por supuesto, no se llaman contenedor Redis iniciado, sino contenedor Walkie iniciado o contenedor Walkie en lugar de contenedor Redis. Pero también podría hacer como una pequeña cosa hexagonal.

Bien. Contenedor Walkie como contenedor Redis. Contenedor Walkie iniciado como contenedor Redis. Y lo que también necesitamos cambiar aquí es la imagen, el nombre de la imagen. Así que, necesitamos revisar Docker Hub nuevamente. En este caso, estoy buscando Walkie. Así que, está este Walkie por Walkie. Y está esta etiqueta. No queremos usar la versión inestable, sino que usamos la versión estable, así que eso es, en este caso, el 7Alpine. Así que, usemos eso. Guardemos esto. Echemos un vistazo a nuestro cliente Docker y ejecutemos esta prueba.

Ejecutar prueba. Ahora, quiere usar Docker nuevamente. Permitimos que mi terminal use Docker. Y ahora, en el fondo, descargará el Walkie Alpine o el Walkie 7, que también es mucho, mucho más pequeño. Como puedes ver, el contenedor estaba ejecutándose. La prueba está pasando, y simplemente reemplazamos usando una herramienta diferente o una biblioteca diferente en lugar de usar Redis, porque Walkie es de código abierto y Redis ya no lo es. Pero no tocamos la lógica aquí. Y, sí, este es también el poder de test container que puede intercambiar fácilmente servicios. Como resumen, test container es una biblioteca para realizar pruebas de integración contra servicios reales. Podría ser una base de datos. Podría ser un corredor de mensajes.

Al encapsular todos los servicios en un contenedor Docker, obtenemos una infraestructura aislada bajo demanda. Lo que quiero decir con eso es que podemos echar un vistazo a la URL de conexión. Pregunta a copilot aquí y luego realiza la prueba bun. Y aquí obtenemos la URL, que está ejecutándose en el puerto 55005. Si realizamos esta prueba nuevamente, tenemos un puerto diferente. Así que es realmente como intentar no entrar en conflicto con otros servicios. Así que realmente intenta ser dinámico y te proporciona este puerto dinámico, por así decirlo.

Por supuesto, nuevamente, ahora tenemos una mayor confianza al enviar esta aplicación. Pero debes tener cuidado de que cada servicio puede tardar mucho tiempo en descargar la imagen. Siempre depende del tamaño de la imagen. Es por eso que lo que ves aquí es, por ejemplo, una imagen de local stack, que tiene un tamaño de 1.15 gigabytes. Usualmente, puedo mostrarte otro proyecto. Este es un proyecto interno en un proyecto de código abierto, en el que estoy trabajando actualmente, que está usando el contenedor de local stack. Y ya está tardando cinco segundos en descargar la imagen.

Y cada ejecutor de pruebas tiene un valor predeterminado de 5000. Por eso estoy encapsulando estos en una función before-all, porque aquí puedo aumentar el valor de tiempo de espera. Así que esto es algo que siempre necesitas considerar al usar test container. Y también fue un poco difícil averiguar las cosas aquí usando local stack. Pero en términos de IA, estuvo bien preguntar a la IA, y realmente me ayudó a hacerlo funcionar. Y sí, para estas grandes imágenes, necesitas tener una estrategia de caché, idealmente un ejecutor autoalojado, o necesitas precalentar tus imágenes. Eso es todo lo que tengo para ti. Gracias por escuchar, y que tengas una gran conferencia por delante. Gracias.