Testcontainers - pruebas unitarias con dependencias reales

• Framework de código abierto que ofrece bases de datos, brokers de mensajes, navegadores web y más, que pueden ejecutarse en contenedores Docker
• No requiere configuraciones de entorno complejas ni objetos simulados (mock); las dependencias de prueba se definen en código y, al ejecutar las pruebas, los contenedores se crean y eliminan automáticamente
• Soporta varios lenguajes y frameworks de prueba, y se puede empezar solo con Docker
• Módulos: prueba todo lo que se pueda contenerizar
  • Se pueden probar diversos componentes, como bases de datos y brokers de mensajes, mediante más de 50 módulos
• Lenguajes compatibles: existen implementaciones de Testcontainers para muchos lenguajes populares, como Java, Go, .NET, Node.js, Python, Rust, Haskell, Ruby, Clojure y Elixir.

Casos de uso: cómo puede ayudar Testcontainers

• Pruebas de integración de la capa de acceso a datos: prueba el código de la capa de acceso a datos usando instancias de base de datos en contenedores
• Pruebas de UI/aceptación: ejecuta pruebas automatizadas de UI usando navegadores web en contenedores compatibles con Selenium
• Pruebas de integración de aplicaciones: ejecuta la aplicación en un modo de prueba temporal con dependencias como bases de datos, colas de mensajes y servidores web, para ofrecer un entorno rico para interacción y pruebas exploratorias

Opinión de GN⁺

• Testcontainers permite a los desarrolladores realizar pruebas en condiciones similares al entorno real, lo que contribuye a mejorar la calidad del software.
• Las pruebas con dependencias reales pueden ofrecer resultados más precisos que usar objetos simulados, aunque en sistemas complejos la configuración y la administración pueden resultar difíciles.
• Otros proyectos con funciones similares a Testcontainers incluyen Docker Compose y Kubernetes Minikube, que también pueden usarse como herramientas para apoyar las pruebas en entornos de desarrollo.
• Al adoptar Testcontainers, se necesita cierto entendimiento de Docker, y puede requerirse conocimiento técnico sobre gestión de contenedores y configuración de red.
• Las ventajas de elegir esta tecnología incluyen la consistencia entre los entornos de desarrollo y prueba, así como una mayor confiabilidad en las pruebas; por otro lado, la dependencia del entorno Docker y la complejidad asociada pueden ser desventajas.

[GN⁺]

Comentarios de Hacker News

• Resumen del primer comentario:

  • No esperaba tantos elogios hacia Testcontainers.
  • Puede parecer atractivo si vienes de un entorno donde no usaban Docker.
  • Es útil en muchos casos de uso, pero es difícil lograr que funcione bien con otros flujos de trabajo basados en contenedores.
  • Testcontainers es una librería cuyo funcionamiento central usa llamadas de shell personalizadas al Docker CLI, lo que provoca problemas y complejidad al introducir otros flujos de trabajo en contenedores.
  • Tiende a asumir que se ejecuta solo en la máquina host y que no hay otras tareas relacionadas con Docker, por lo que a menudo puede ser peor, o incluso mucho peor, que librerías para entornos no Docker.

• Resumen del segundo comentario:

  • Testcontainers es un cambio total de juego para las pruebas de integración.
  • Proporciona APIs de Docker por lenguaje para levantar contenedores fácilmente y verificar si ya están listos para conexiones.
  • Lo uso en todos los proyectos nuevos para pruebas de integración.
  • La configuración de CI incluye linting, build, pruebas unitarias y pruebas de integración usando Testcontainers.
  • Los bindings por lenguaje ofrecen funciones helper útiles para trabajar con bases de datos.

• Resumen del tercer comentario:

  • No entiende por qué sería mejor que usar docker-compose.yml.
  • Testcontainers es relativamente débil cuando hay dependencias complejas entre los contenedores necesarios.
  • Lo probó hace 5 años, aunque puede que ahora la situación haya mejorado mucho.

• Resumen del cuarto comentario:

  • Considera muy valiosas las pruebas de integración que usan una base de datos real/Elasticsearch/Redis/Varnish, etc.
  • Testcontainers se encarga de tareas como crear un nuevo índice de Elasticsearch durante la suite de pruebas y apagarlo después.
  • Prefiere una estrategia que cubra la mayor cantidad posible de funcionalidades de la aplicación con pruebas de estilo de integración end-to-end.
  • Usa pruebas unitarias solo en partes del código con pares claros de entrada/salida, y usa mocks para cosas como llamadas a APIs externas que no puede controlar.

• Resumen del quinto comentario:

  • Hace unos 7 años escribió conex, una implementación de Testcontainers para Go.
  • Ofrece integración de primera clase con el framework oficial de pruebas de Go.

• Resumen del sexto comentario:

  • Hay quien opina que proporcionar una instancia nueva y limpia del navegador para cada prueba es lento.
  • Si ya invertiste en el mundo de los contenedores, está bien aceptar algunos contenedores adicionales.
  • Si no es así, no hay mucho beneficio frente a la complejidad o el peso extra.

• Resumen del séptimo comentario:

  • Revisó Testcontainers y creó su propia versión.
  • Docker es una abstracción con muchas fugas, y hay que ejecutar pruebas en distintos entornos.
  • La red funciona de manera completamente distinta en Mac, en una VM de Linux y dentro de un contenedor Docker en una VM de Linux con el socket de Docker montado.
  • Quiere ejecutar pruebas en paralelo y mostrar logs correspondientes a cada prueba.
  • No está seguro de si Testcontainers ya resolvió estos problemas, pero aprendió que el diablo está en los detalles.

• Resumen del octavo comentario:

  • Crea el entorno local de pruebas con docker-compose.
  • Testcontainers parece una abstracción en lenguaje de programación para definir un entorno Docker sin tener que aprender la sintaxis de Docker Compose.
  • Para saber si el entorno de pruebas está listo para usarse, igual hace falta entender redes de Docker, dependencias y health checks.

• Resumen del noveno comentario:

  • No se necesitan mocks ni una configuración compleja del entorno.
  • Defines las dependencias de prueba en código y, al ejecutar la prueba, los contenedores se crean y se eliminan.
  • Pensar que ya no hacen falta pruebas unitarias solo porque puedes ejecutar pruebas de integración con contenedores es un malentendido.
  • Configurar contenedores Docker es sencillo, pero arrancarlos es doloroso y lento.

• Resumen del décimo comentario:

  • Es una pregunta sobre usar a Duke como logo de Java.