De hecho, puede obtener un Postgres real para que funcione bien en un entorno de prueba.

También le sugiero que use una base de datos dockerizada, pero use tmpfs para mapear en memoria la carpeta de datos:

 docker run --name postgres95 -p 5432:5432 --tmpfs /var/lib/postgresql/data:rw -e POSTGRES_PASSWORD=admin -d postgres:9.5.6

Esto es lo más cercano a "en memoria" que puede obtener usando la cosa real.

Creo que uno de los principales problemas con las pruebas de integración lenta no es el rendimiento de la base de datos en sí, sino el tiempo que lleva configurarla para cada prueba.

Escribí una pequeña biblioteca para ayudarlo a restaurar rápidamente una base de datos a un estado 'limpio'. De esta manera, solo necesita ejecutar costosas migraciones de bases de datos una vez y luego puede restaurar rápidamente la base de datos para cada prueba.

Lo usamos en un sistema productivo para obtener una aceleración 4x en nuestras pruebas de integración:

https://github.com/ayedo/postgres-db-restore

Esta pregunta pide opiniones, pero aquí va:

Si desea probar una aplicación que usará PostgreSQL, deberá usar PostgreSQL para sus pruebas. Los dialectos y el comportamiento de SQL varían demasiado entre los diferentes sistemas de administración de bases de datos.

Puede hacer que PostgreSQL sea bastante rápido si usa una base de datos que sea lo suficientemente pequeña como para caber en la RAM, lo que debería ser posible para las pruebas de integración que solo se enfocan en la funcionalidad, no en el rendimiento general.

Algunas de mis pruebas de db en postgres reales toman 10 ms cada una. y hago varias confirmaciones en cada prueba. asi que:

Para tener cobertura de características nativas de postgres, necesita la misma base de datos (como notó, h2 y otras bases de datos en memoria no son muy compatibles). postgres no tiene modo en memoria. Para las pruebas funcionales, la base de datos real en sí misma no es mucho más lenta que cualquier base de datos en memoria. La diferencia generalmente radica en el tiempo de inicio (para postgres 9.6 es ~4s). Pero si su ciclo de vida de prueba es inteligente y puede reducir el número de inicios de db a 1 o 0 (al tener el db de desarrollo siempre listo), entonces el problema deja de ser notable.

así que obtenga el postgres real y configure su ciclo de vida correctamente. Hay algunas herramientas que pueden ayudarte a resolver algunos de los problemas:

1. testcontainers lo ayudará a proporcionar una base de datos real.

2. dbunit : lo ayudará a limpiar los datos entre pruebas

   contras:

   • se requiere mucho trabajo para crear y mantener el esquema y los datos. especialmente cuando su proyecto se encuentra en una etapa de desarrollo intensivo.
   • es otra capa de abstracción, por lo que si de repente desea utilizar alguna función de db que no es compatible con esta herramienta, puede ser difícil probarla

3. testegration : intenta proporcionarle un ciclo de vida completo, listo para usar y extensible (divulgación: soy un creador).

   contras:

   • gratis solo para pequeños proyectos
   • proyecto muy joven

otro paso sería mover db a la memoria en el nivel del sistema operativo. nuevamente, el primer tiempo de inicio sería similar ya que todo debe cargarse. algunos puntos de partida aquí y aquí

contras:

• cada desarrollador en su equipo tiene que modificar su entorno local
• no es portátil entre sistemas operativos (si su equipo tiene entornos heterogéneos)