Objektrelationales Mapping mit JPA Testing Jonas Bandi Simon Martinelli
Testen mit Einbezug der DB Schwierigkeit: Die DB repräsentiert den Zustand unseres Systems Oft enthält die DB den Input und den Output unseres Tests Um gezielt und deterministisch zu Testen müssen wir den DB Zustand kennen und beeinflussen Zusätzlich: Fast immer enthält die DB auch Logik (Constraints sind auch Logik)
Unit- vs. Integration Tests Mocking der DB soweit möglich: Einbindung der DB – DB in einen definierten Zustand bringen – Tests durchführen – Veränderungen verifizieren – (Aufräumen)
Mocking DAOs sind ein guter Ansatzpunkt – Zentraler Zugriffspunkt, klares Interface – Formulierung der Erwartungen an den Data- Access Layer mit Business Semantik – Erwartungen können gegen die DB gestestet werden Mocking der JPA-Infrastrukur – Möglich, aber aufwändig (EntityManager, Query) – Viel technische Komplexität, kein Business Value
In-Memory Datenbank HSQLDB und Derby reife Datenbanken mit einem In-Memory Mode DB wird für jeden Test neu gestartet und initialisiert – Einfache Integration, lokale Datenbank – Keine Seiteneffekte – Schema immer aktuell – Die meisten Persistenz bezogenen Probleme können erkannt werden
Mehrstufige Testing Strategie Unit-Tests mit Mocking – Testen von Business Komponenten in Isolation – Korrektes Verhalten bezüglich erwartetem Business Funktionale Tests mit In-Memory Datenbank – Korrektes Verhalten mit Einbezug der Persistenz-API – Sehr einfache Integration, schnell, lokal – Setup/Teardown pro Test Integrations Tests gegen Produktions-Datenbank – Produktives Verhalten – Wenn möglich mit produktiven Datenbeständen – Komplizierteres Setup/Teardown, langsam
Testdaten Management Wichtiges Thema das früh im Projekt angegangesn werden sollte Wer liefert valide Testdaten Wie und wann werden Testdaten in die verschiedenen DBs eingespielt Schema-Migrationen Patterns für Unit-Tests: – Object Mother, Test Data Builder