Testcontainers: una base de datos real durante los tests

El equipo tiene tres opciones, y las tres plantean problemas. Una base de datos PostgreSQL compartida en un servidor de integración: dos ejecuciones simultáneas se pisan, un test deja una fila a su paso y rompe el del vecino, y nadie se atreve a reiniciarla. Una base de datos local instalada en cada equipo: cada uno tiene su versión, sus extensiones y su esquema ligeramente desfasado, y la llegada de un nuevo desarrollador cuesta media jornada. Una base de datos en memoria tipo H2: rápida, uniforme y ciega a todo lo que es específico de PostgreSQL, como vimos en la primera lección.

Testcontainers propone una cuarta vía: la suite de tests arranca por sí misma un contenedor Docker con PostgreSQL, le aplica el esquema, ejecuta los tests y después destruye el contenedor. La versión es la que se declara en el código, por lo que es idéntica en todas partes. El aislamiento es total, así que la ejecución en paralelo es posible. Y como es un PostgreSQL de verdad, jsonb, ILIKE, los índices GIN y las restricciones de exclusión se comportan exactamente igual que en producción. El precio que hay que pagar es real —Docker pasa a ser una dependencia de la suite y el arranque consume tiempo— y la mayor parte de esta lección trata precisamente de cómo contener ese precio.