EJB3Unit extension de JUnit pour les applications EJB3/JPA

Je me suis posé à nouveau le problème des tests unitaires dans le cadre d’applications EJB3/JPA, en fait deux applications. Ces applications contiennent grossièrement trois couches. La couche externe est un ensemble de stateless session beans. La couche intermédiaire sont des « queries », ce sont des stateless session beans simples effectuant des recherches dans la base de donnés. Enfin la dernière couche sont les entités des objet persistants contenant du métier.

La particularité de mes applications est bien que le métier se trouve essentiellement dans les entités et non dans les sessions beans qui eux effectue des tâches essentiellement techniques comme la gestion de la transactions. Attention, JPA est un peu limité par rapport à Hibernate et certains traitements doivent être placés au niveau des session beans.

Autre point important dans l’architecture est de respecter le principe suivant : statefull session beans > stateless session beans > entities. Ce qui signifie qu’un statefull session bean peut appeler des statefull session beans, des stateless session beans et des entités. Un stateless session bean peut appeler des stateless session beans et des entités, mais jamais de statefull session beans. Enfin, une entité ne peut appeler que des entités.

Ce dernier point rend les entités complètement indépendantes de JPA. Il est donc possible de faire les tests unitaires sans se préoccuper de la partie persistance. Ce qui renforce l’impression de framework « transparent » pour JPA.

Tester les queries et les session beans est plus complexe. Pour ces dernier, il faut un conteneur EJB3. J’utilise OpenEJB qui permet d’avoir un conteneur simple à utiliser lors de mes test. Enfin, il faut des donnés de tests. Actuellement, j’utilise des scripts SQL pour initier des donnés de test pour les queries. Enfin pour les session beans, j’utilise des méthodes qui alimentent la base de données. Ce dernier point peut devenir très lourds pour les session beans gérant les entités les plus complexes.

Ce principes d’écriture des tests unitaires fonctionnaient à près bien sans être tout à fait satisfaisant, au moins pour ma première application. En effet la base de données après les tests est polluée par les données de test introduites. Cependant, ceci devient ingérable pour ma seconde application, soit trop complexe, soit mal écrite…

J’ai appris l’existence de EJB3Unit récemment. En fait, cet outil montre quelque chose d’essentiel. Tout comme les servlets et filtres Java, les session beans sont des objets utilisables uniquement dans un conteneur (de servlets pour les servlets et les filtres). Ils nécessite un framework particulier de test. Pour les servlets, il s’agit de Cactus, pour les session beans EJB3 se serait EJB3Unit. Par contre du fait de la transparence de la persistance, EJB3Unit n’a pas d’intérêt pour les entités. J’ai bien mis le conditionnel, car ce projet semble abandonné par ces développeur depuis plus d’un an. Et la dernière version stable est incompatible avec mes applications EJB3.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s


%d blogueurs aiment cette page :