Así que pensé en usar el modo de compatibilidad H2 PosgreSQL al pensar que todas las consultas de postgres funcionarán en H2, corríjame si me equivoco
Me temo que eso no es cierto.
H2 intenta emular la sintaxis de PostgreSQL y admitir algunas funciones y extensiones. Nunca coincidirá por completo con el comportamiento de PostgreSQL y no es compatible con todas las funciones.
Las únicas opciones que tiene son:
- Usar PostgreSQL en las pruebas; o
- Dejar de usar funciones no compatibles con H2
Sugiero usar Pg para probar. Es relativamente simple escribir un arnés de prueba que initdb es una instancia de postgres y lo lanza para probarlo y luego lo desarma.
Actualización basada en comentarios:
No hay una línea clara entre las pruebas de "unidad" y las de "integración". En este caso, H2 también es un componente externo. Las pruebas unitarias puristas tendrían un respondedor ficticio a las consultas como parte del arnés de prueba. La prueba contra H2 es tanto una prueba de "integración" como la prueba contra PostgreSQL. El hecho de que esté en proceso y en memoria es conveniente, pero no funcionalmente significativo.
Si desea prueba unitaria debe escribir otro objetivo de base de datos para que su aplicación vaya junto con sus objetivos "PostgreSQL", "SybaseIQ", etc. Llámelo, digamos, "MockDatabase". Esto debería devolver los resultados esperados de las consultas. Realmente no ejecuta las consultas, solo existe para probar el comportamiento del resto del código.
Personalmente, creo que es una gran pérdida de tiempo, pero eso es lo que haría un purista de pruebas unitarias para evitar introducir dependencias externas en el arnés de prueba.
Si insiste en tener pruebas unitarias (en lugar de integración) para sus componentes de base de datos pero no puede/no quiere escribir una interfaz simulada, debe encontrar una manera de usar una existente. H2 sería un candidato razonable para esto, pero tendrá que escribir un nuevo backend con un nuevo conjunto de consultas que funcionen para H2, no puede simplemente reutilizar su backend de PostgreSQL. Como ya establecimos, H2 no es compatible con todas las funciones que necesita para usar con PostgreSQL, por lo que tendrá que encontrar diferentes formas de hacer lo mismo con H2. Una opción sería crear una base de datos H2 simple con resultados "esperados" y consultas simples que devuelvan esos resultados, ignorando por completo el esquema de la aplicación real. El único inconveniente real aquí es que puede ser un gran dolor de mantenimiento... pero eso es prueba unitaria.
Personalmente, solo probaría con PostgreSQL. A menos que esté probando clases individuales o módulos que son independientes como unidades bien definidas de interfaz estrecha, no me importa si alguien lo llama prueba de "unidad" o "integración". Haré pruebas unitarias, digamos, clases de validación de datos. Para el código de interfaz de base de datos, las pruebas unitarias puristas tienen muy poco sentido y solo haré pruebas de integración.
Si bien tener una base de datos en memoria en proceso es conveniente para eso, no es necesario. Puede escribir su arnés de prueba para que el código de configuración initdb s un nuevo PostgreSQL y lo lanza; luego, el código de desmontaje mata al administrador de correos y elimina el directorio de datos. Escribí más sobre esto en esta respuesta.
Véase también:
- Ejecutar PostgreSQL solo en la memoria
En cuanto a:
Si todas las consultas con conjuntos de datos finales esperados funcionan bien en Postgress, puedo suponer que funcionará bien en todos los demás dbs
Si entiendo lo que dice correctamente, entonces sí, ese es el caso, si el resto de su código funciona con un conjunto de datos de PostgreSQL, generalmente debería funcionar igual con un conjunto de datos que contiene los mismos datos de otra base de datos. Siempre y cuando utilice tipos de datos simples y no características específicas de la base de datos, por supuesto.
