Testar contra o real em vez de contra um simulacro

Sua suíte de testes está verde. Trezentos e quarenta testes, onze segundos, nenhuma falha. Você faz o deploy, e a primeira requisição em produção falha com ERROR: column "created_at" is of type timestamp with time zone but expression is of type character varying. Ninguém introduziu um bug: o código testado é exatamente o código implantado. O que mudou foi o banco. Seus testes conversavam com o H2 em modo de compatibilidade PostgreSQL, enquanto a produção conversa com o PostgreSQL 16. O H2 aceitava a conversão implícita, o PostgreSQL a recusa. Sua suíte não mentiu sobre o seu código, mentiu sobre o ambiente dele.

Esse cenário não tem nada de exótico. O H2 não conhece jsonb, não aplica as mesmas regras de ordenação de strings conforme a collation, aceita nomes de coluna que o PostgreSQL reserva, e trata os níveis de isolamento transacional com uma flexibilidade que Oracle ou SQL Server não têm. Cada diferença é pequena. Juntas, formam uma categoria inteira de defeitos que sua suíte estruturalmente não consegue detectar, e sobre os quais você não tem nenhum sinal antes do deploy. O problema não é o H2: é acreditar que um teste que passa contra o H2 diz alguma coisa sobre o PostgreSQL.