JPA gegen echtes Oracle verifiziert

Beispiel: OraclePersistenceIT (novaris-integration-tests).

Bis Phase 5 wurde die Policy-Entity und ihr LocalDateAttributeConverter (siehe deren Javadoc in novaris-policy-core) nie gegen eine echte Datenbank geprueft - die Unit-Tests aus Phase 1 mocken PolicyRepository vollstaendig weg. Das ist bewusst so (schnelle, containerfreie Tests fuer die Geschaeftslogik), heisst aber auch: ein subtiler Mapping-Fehler (z.B. ein LocalDate, das durch Zeitzonenverschiebung am naechsten Tag landet) waere in keinem der bisherigen Tests aufgefallen. OraclePersistenceIT schliesst genau diese Luecke.

Zwei Persistence Units fuer denselben Entity-Code, ein bewusster Unterschied

Die produktive Persistence Unit (novarisPolicyPU, novaris-policy-core) ist transaction-type="JTA" mit einer <jta-data-source> - korrekt fuer den Betrieb in einem Java-EE-Container, der Transaktionsmanager und JNDI-Datenquelle bereitstellt. Ausserhalb eines Containers gibt es beides nicht. novaris-integration-tests definiert deshalb eine zweite, eigene Persistence Unit (novarisPolicyIT_PU, src/test/resources/META-INF/persistence.xml) mit transaction-type="RESOURCE_LOCAL", die dieselben Entity-/Converter-Klassen referenziert, aber ihre Verbindung selbst verwaltet (EntityManager.getTransaction().begin()/commit() statt eines Containers).

Diese zweite Persistence Unit ist kein Kompromiss an der Aussagekraft des Tests - sie prueft exakt dasselbe O/R-Mapping (Tabellen-/Spaltennamen, @Convert, Typen) gegen dieselbe Datenbank-Engine. Der einzige Unterschied liegt in der Transaktionsverwaltung, die mit dem eigentlichen Mapping nichts zu tun hat.

Was der Test konkret beweist

Policy policy = new Policy("NOV-IT-1", "CUST-IT-1", "HAUSRAT", PolicyStatus.ACTIVE,
        12_345L, LocalDate.of(2026, 3, 1), LocalDate.of(2027, 3, 1));
entityManager.persist(policy);
// ... commit, clear (Persistence-Context-Cache leeren, damit wirklich aus der DB gelesen wird) ...
Policy loaded = entityManager.createQuery(..., Policy.class).getSingleResult();

assertEquals(LocalDate.of(2026, 3, 1), loaded.getCoverageStartDate());

Das entityManager.clear() vor dem erneuten Laden ist entscheidend: ohne es koennte JPA das bereits im Persistence-Context-Cache gehaltene Java-Objekt zurueckgeben, ohne ueberhaupt erneut mit der Datenbank zu sprechen - der Test wuerde dann nur beweisen, dass Java sich an sein eigenes Objekt erinnert, nicht dass die Datenbank-Rundreise (inklusive LocalDateAttributeConverter in beide Richtungen) tatsaechlich funktioniert.

Testcontainers-Ersatz per Docker-CLI

Genau wie bei IBM MQ (siehe docs/30-jms-mq/04-ibm-mq-vs-activemq-ersatz.md) orchestriert OraclePersistenceIT den Oracle-Container ueber DockerCli (Docker-Kommandozeile) statt der Testcontainers-Bibliothek - siehe novaris-integration-tests/README.md fuer die Begruendung. Verwendetes Image: gvenzl/oracle-free:23-slim (freies, Testcontainers- uebliches Oracle-Image, keine Lizenzwand).