Bases de datos efímeras en contenedores para pruebas de integración

Objetivo

Ejecutar las pruebas de acceso a datos y de integración contra el motor de base de datos real, iniciado desde cero para cada ejecución, de modo que las pruebas detecten el comportamiento de dialecto, de restricciones y de transacciones que un sustituto en memoria o un repositorio simulado (mock) oculta.

Requisitos previos

Un entorno de ejecución de contenedores en las máquinas de desarrollo y en la integración continua; migraciones que puedan aplicarse desde cero con una sola orden; pruebas que lean la configuración de conexión desde la configuración en lugar de asumir un puerto fijo o una base de datos ya existente.

Pasos

1. Iniciar el motor una vez por ejecución de pruebas, no una vez por prueba. Testcontainers se describe a sí mismo como un proveedor de instancias ligeras y desechables de bases de datos en contenedores Docker, iniciadas desde el código de prueba y eliminadas después; la alternativa sencilla es docker run con un puerto publicado aleatorio que se vuelve a leer desde el entorno de ejecución.
2. Situar el directorio de datos en un montaje tmpfs (--tmpfs con docker run) y relajar los ajustes de durabilidad del motor para un uso que no sea de producción, ya que los datos son desechables.
3. Aplicar las migraciones una sola vez a una base de datos plantilla. La documentación de PostgreSQL indica que CREATE DATABASE funciona copiando una base de datos existente, de modo que CREATE DATABASE t_42 TEMPLATE t_base da a cada archivo de pruebas una copia nueva sin volver a ejecutar las migraciones. La base de datos de origen no debe tener otras conexiones mientras se copia.
4. Elegir una sola estrategia de aislamiento y aplicarla en todas partes: una base de datos nueva por archivo de pruebas, una transacción por prueba que se revierte, o el truncado de las tablas que haya tocado una prueba.
5. Generar los ajustes de conexión a partir del contenedor en ejecución y pasarlos por la misma vía de configuración que usa la aplicación en producción, de modo que la prueba cubra también la gestión de la configuración.
6. Fijar la etiqueta de la imagen a la versión mayor de producción y usar la misma configuración en local y en la integración continua.

Resultado esperado

Las pruebas ejercitan el planificador de consultas real, las restricciones, los niveles de aislamiento y las funciones de extensión; una ejecución correcta significa que el esquema y las consultas concuerdan, y una migración que rompe una consulta falla antes del despliegue.

Límites y base de verificación

El arranque añade segundos a cada ejecución, así que conviene mantener las pruebas unitarias puras en una suite separada y más rápida. Testcontainers documenta la reutilización de un contenedor entre ejecuciones como una función experimental de adhesión voluntaria que no es adecuada para su uso en integración continua. Una transacción revertida no puede probar código que confirma (commit), que usa varias conexiones o que depende de disparadores que se activan al confirmar. Una base de datos gestionada en la nube puede diferir de la imagen en extensiones y parámetros; este método prueba el motor, no el servicio gestionado. No se afirma ningún tiempo de ejecución.