Simple et fiable dans la base de données de mémoire pour les tests d'intégration java rapide avec le support de JPA

Question

Mes tests d'intégration s'exécuteraient beaucoup plus rapidement si j'utilisais la base de données en mémoire au lieu de PostgreSQL. J'utilise JPA (Hibernate) et j'ai besoin d'une base de données en mémoire qui serait facile à utiliser en utilisant JPA, facile à installer et fiable. Il doit supporter JPA et Hibernate (ou vice versa si vous voulez) assez largement puisque je n'ai aucun désir d'adopter mon code d'accès aux données pour les tests.

Quelle base de données est le meilleur choix compte tenu des exigences ci-dessus?

Answer 1

Pour tests d'intégration, j'utilise maintenant H2 (de l'auteur original de HSQLDB) que je préfère HSQLDB. C'est faster (et je veux que mes tests soient aussi rapides que possible), il a quelques fonctionnalités intéressantes comme le mode compatibility, l'équipe de développement est très réactive (alors que HSQLDB est resté en sommeil pendant des années jusqu'à très récemment).

Answer 2

J'ai utilisé HSQLDBin-memory pour les tests d'intégration de la persistance JPA/Hibernate en Java. Démarre assez rapidement, ne nécessite aucune configuration spéciale. Le seul problème que j'ai vu jusqu'ici avec l'utilisation de HSQLDB avec Hibernate était de faire avec la taille de lot devant être définie sur 0, mais cela pouvait simplement être lié à une ancienne version. Je vais creuser et voir si je peux trouver les détails de ce problème.

Derby supports an in-memory mode ces jours-ci, il n'est plus marqué expérimental.

Answer 3

J'utilise Derby. D'une part, il y a environ 3 lignes de code par test unitaire en moins, car il n'y a pas besoin d'un arrêt après le test. Cependant, vous devez utiliser une implémentation JPA qui peut supprimer et créer des tables telles qu'EclipseLink.

Derby peut également initialiser une nouvelle base de données en mémoire à partir d'un fichier afin que vous puissiez avoir une base de données de référence et y revenir à tout moment. Pour les tests unitaires cependant, je préfère créer mes objets dans la logique @Before de mon test unitaire. Je trouve cela plus facile surtout avec JPA car cela me permet de faire des refactorings et de ne pas m'inquiéter de la structure de base de données sous-jacente. Les outils tels que DBunit reposent sur une structure pratiquement statique et le refactoring implique de modifier manuellement les XML DBunit plutôt que de se fier aux capacités de refactoring d'Eclipse.