Seulement, j'aime bien aussi utiliser dbUnit pour insérer des données de test prévisibles avant mes tests. Et là ça se complique sérieusement, car il faut passer à dbUnit la connexion JDBC associée à la transaction utilisée par l' EntityManager JPA (vous suivez ?)
Le problème, c'est que spring-test-context ne propose par de méthode listener au sein de la transaction (SPR-4365) ; seulement avant ou après. J'ai donc du étendre le "TransactionalTestExecutionListener" pour ajouter dans beforeTestMethod l'injection des données dbUnit.
La mauvaise surprise, c'est qu'en l'absence d'une indication explicite, Spring utilise un DefaultJpaDialect incapable d'identifier la Connection JDBC utilisée, mais ce n'est pas considéré comme un cas d'erreur donc dbUnit ne partage pas la même connexion :'(
Ajoutez à ça une connexion qui est par défaut en autocommit, des tables Oracle AQ$TRUC qui viennent pourrir les données de test et ça vous donne une idée de mes trois derniers jours :-/
Pour résumer, si vous voulez faire comme moi :
- N'oubliez pas de préciser le jpaVendorAdapter (HibernateJpaVendorAdapter) dans la définition Spring de votre entityManagerFactory
- Utilisez DataSourceUtils pour récuperer la connexion associée à la transaction JPA en cours
et là, miracle, ça marche enfin :)
Etape suivante : faire un merge à la volée entre les deux persistence.xml qui vont constituer mon contexte JPA (SPR-2598), le permier étant "mutualisé" avec une autre application ...
