Tester contre le réel plutôt que contre un simulacre

Votre suite de tests est verte. Trois cent quarante tests, onze secondes, aucun échec. Vous déployez, et la première requête en production échoue sur ERROR: column "created_at" is of type timestamp with time zone but expression is of type character varying. Personne n'a introduit de bug : le code testé est exactement le code déployé. Ce qui a changé, c'est la base. Vos tests parlaient à H2 en mode compatibilité PostgreSQL, la production parle à PostgreSQL 16. H2 acceptait la conversion implicite, PostgreSQL la refuse. Votre suite n'a pas menti sur votre code, elle a menti sur son environnement.

Ce scénario n'a rien d'exotique. H2 ne connaît pas jsonb, ne fait pas respecter les mêmes règles de tri sur les chaînes selon la collation, accepte des noms de colonne que PostgreSQL réserve, et traite les niveaux d'isolation transactionnelle avec une souplesse que Oracle ou SQL Server n'ont pas. Chaque écart est petit. Ensemble, ils forment une catégorie entière de défauts que votre suite ne peut structurellement pas détecter, et sur lesquels vous n'avez aucun signal avant le déploiement. Le problème n'est pas H2 : c'est de croire qu'un test qui passe contre H2 dit quelque chose sur PostgreSQL.