Comment testez-vous vos entités en JPA ?

**fisico** · 07/05/2008, 21h50

Bonjour à tous,

Je lance une sorte de débat sans avoir réellement de prétention.

Actuellement, je travaille sur un projet longue durée où nous utilisons JPA. Le développement des entités en JPA fait partie de mon boulot quotidien et le domaine compte environ une trentaine d'entités. Comme dans toute application, il faut tester les composants qui ont été créés. Particulièrement, parce que le domaine physique est écrit par un ingénieur base de données en Oracle. Ce qui signifie que il n'y a pas de génération automatique des tables. Le but des tests unitaires est dans ce cas-ci de contrôler que les entités vont bien être persistées.

Que testez-vous ?
Et comment le testez-vous ?

Alexis

**fisico** · 07/05/2008, 22h02

Un article sur un blog correspondant à ce sujet:

http://eskatos.wordpress.com/2007/10...mory-database/

**eskatos** · 31/07/2008, 22h49

Salut,

Je continue d'utiliser la méthode décrite dans le blog cité par fisico pour tester les entités en utilisant directement un EntityManager mais aussi pour tester mes DAOs sans aucun soucis.

Evidemment ça ne remplace pas des tests d'intégrations menés avec le SGBD utilisé en production car les implémentations de JPA utilisent différement les SGBDs sous-jacents.

Paul

**xv-mnt** · 07/08/2008, 12h26

Pour ma part, notre équipe architecture mous a pondu quelques classes utilitaires qui permettent de changer :
- le type de transaction utilisée : soit JTA lorsque le projet est déployé sur notre serveur, soit RESOURCE_LOCAL lors des tests unitaires. Pour celà, il faut 2 fichiers persistence.xml. Le premier sera inséré dans l'EAR, et le second ne sera visible que lors des tests unitaires.
- le type de base de données : HSQLDB ou ORACLE pour les tests unitaires, suivant ce que l'on veut faire. Pour éviter la multiplication les DB ORACLE (+ lourd à maintenir), on a choisi de faire tourner les tests unitaires sous hsqldb.
Ainsi, les différents développeurs ne se marchent pas dessus lors des tests.
On a cependant une base ORACLE pour les tests unitaires exécutés lors de l'intégratio continue. Les paramètres de connexion sont définis dans un fichier de configuration.
Pour info, nos builds utilisent maven, et le build continu se fait avec CruiseControl.

**vbrabant** · 19/08/2008, 20h56

Tu peux toujours regarder comment nous faisons nos tests : http://java.developpez.tv/suntechdays2007/#vid19

Vincent

**SuperPat** · 20/08/2008, 14h19

Pour notre part, nous utilisons le framework TestNG pour lancer les tests unitaires et avec version embedded du noyeau JBoss avec lequel nous déployons nos EJB3, et il suffit d'un lookup sur notre facade pour tester toute la chaine métier justqu'à la couche persistance.

**adamo901** · 20/08/2008, 18h03

En ce qui me concèrne, je n'ai jamais fais des tests pour la partie JPA de mes projets.

Je n'en ai jamais eu besoins puisque Netbeans me crée automatiquement mes Entities et la gestion du CRUD et si facile avec le EntityManager.

**nicorama** · 22/08/2008, 14h40

Envoyé par adamo901

En ce qui me concèrne, je n'ai jamais fais des tests pour la partie JPA de mes projets.

Je n'en ai jamais eu besoins puisque Netbeans me crée automatiquement mes Entities et la gestion du CRUD et si facile avec le EntityManager.

C'est un peu la question que je me pose : utiliser un ORM, c'est bien quand tout est géré par l'ide : ca fait gagner un temps fou.

Mais si on complexifie le système, à quoi bon utiliser l'orm au lieu de tout faire à la mano avec jdbc et du xml via JDOM ? C'est pas franchement plus compliqué, bien plus souple, plus évolutif, ca diminue le nombre de classes par 3 et il n'y a pas de fichiers xml de config.

Je précise que c'est la question d'un noobs en ORM

**christopheJ** · 24/08/2008, 14h33

On ne multiplie pas forcement les classes par trois.
Le pattern DAO avec un DAO par entity n'est pas obligatoire.
L'EntityManager me sert de DAO générique, je n'ai donc pas de classes supplémentaire.

Pour l'aspect CRUD je fais confiance au framework, par contre il m'arrive d'utiliser DBUnit pour tester mes requetes JPQL.
Voir la vidéo donnée par vbrabant plus haut pour l'utilisation.

**slevy** · 25/08/2008, 13h34

Pour ma part j'utilise JUnit et Spring pour tester mes DAO Hibernate.

Matt Raible dans cette présentation explique plusieurs de ces techniques :
https://appfuse.dev.java.net/TDDWithAppFuse.pdf

**heid** · 25/08/2008, 14h05

J'utilise DBUnit avec des tests unitaires à la main.

Hélas l'implémentation JPA que j'utilise (KODO) me pose de sérieux problème de fiabilité des tests (n'est ce pas christophe...

) : des méthodes échouent en tests mais fonctionnent parfaitement dans l'application, et nous avons recours à quelques bidouilles pour tester les EJB en mode local et sans conteneur (injection manuelle des datasources et entitymanagers).

**spall** · 08/02/2010, 22h20

Envoyé par slevy

Pour ma part j'utilise JUnit et Spring pour tester mes DAO Hibernate.

Matt Raible dans cette présentation explique plusieurs de ces techniques :
https://appfuse.dev.java.net/TDDWithAppFuse.pdf

même chose pour moi.

http://static.springsource.org/sprin...e/testing.html

**geforce** · 18/07/2011, 12h17

Bonjour,

je voudrais faire des Tests Unitaire pour tester DAO (tout ce qui est CRUD)

Mais sans utiliser Spring, dit mois si ces possible ? est Eventuellement comment (façon de faire) ?

PS: j'utilise JEE6, EJB3.1, Junit4

**DevServlet** · 19/07/2011, 13h57

Envoyé par geforce

Bonjour,

je voudrais faire des Tests Unitaire pour tester DAO (tout ce qui est CRUD)

Mais sans utiliser Spring, dit mois si ces possible ? est Eventuellement comment (façon de faire) ?

PS: j'utilise JEE6, EJB3.1, Junit4

Moi j'utilise Junit pout tester ,et Spring pour injecter mes EAO dans ma classe de Test.

**geforce** · 20/07/2011, 12h46

Envoyé par DevServlet

Moi j'utilise Junit pout tester ,et Spring pour injecter mes EAO dans ma classe de Test.

tu veux dire DAO ! a la place de EAO

**DevServlet** · 20/07/2011, 13h39

Non je parle bien d'EAO, les DAO dans ma boite c'est pas pour attaquer les entités, mais pour faire du sql natif. C'est juste une question de définition.