Comment tester facilement un EJB en utilisant JUnit

Question

Je veux tester un bean Java d'entreprise (qui devrait être déployé ultérieurement sur un serveur JBoss) en utilisant JUnit. Mais je ne sais pas exactement comment les outils que je peux utiliser pour cela. Le JUnit ordinaire échoue en raison du conteneur EJB manquant et du manque d'injections nécessaires. Googler un peu autour de moi conduit à une bibliothèque appelée conteneur JBoss EJB embedded, mais il semble qu'il est obsolète. Je n'ai pas non plus trouvé de source ou de fichiers binaires à télécharger.

Alors, s'il vous plaît, aidez-nous, comment générer localement un conteneur "fictif" capable d'exécuter les tests JUnit sur les enterprise beans?

Salutations Ben

Answer 1

Vous pouvez utiliser un EJB client distant dans votre programme JUnit pour tester votre EJB. Le seul inconvénient est que vous devez avoir un serveur d'applications en cours d'exécution pendant les tests.

Découvrez this blog entry pour un exemple sur la façon d'appeler un EJB à distance.

Answer 2

Je vous suggère de jeter un oeil à Arquillian:

Arquillian vous permet de tester votre logique métier dans un conteneur à distance ou intégré. Alternativement, il peut déployer une archive dans le conteneur afin que le test puisse interagir en tant que client distant.

Il existe encore une vie Embedded JBoss AS. Le Seam Framework fournit également un environnement de test avec un JBoss intégré pour exécuter les tests de composants (avec TestNG) de votre application.

Answer 3

openEJB est un conteneur EJB intégré qui convient parfaitement aux EJB de tests unitaires. Vous pouvez les tester en dehors de votre serveur d'applications normal. Et c'est rapide! Et, ça tourne vite! Et, il a un plugin Eclipse pour une gestion facile! Je dois aimer ça! Il existe depuis longtemps, il existe de nombreux tutoriels sur la façon de le configurer et de l'utiliser, donc vous ne devriez pas avoir de problèmes avec cela.

Answer 4

Cela fait un moment, mais j'ai toujours écrit mes EJB comme de simples wrappers de POJOs. Une interface définirait les méthodes, et à la fois le POJO et l'EJB (session, bien sûr) implémenteraient cette interface.

Je pourrais tester entièrement la "logique métier" des POJO sans aucun problème de conteneur. Puis si j'avais le serveur en cours d'exécution, je pouvais exécuter les mêmes tests contre la fève de session, juste en test contre le client au lieu de POJO ...

Answer 5

Comme je ne pas besoin de trucs JNDI (par exemple Cannot instantiate class: org.jnp.interfaces.NamingContextFactory) tout à fait dans mon DAO (interface ORM) tests, il me suffisait de

• comprennent les pots de mise en veille prolongée dans le classpath
• supprimer/outcomment la partie <jta-data-source>...</jta-data-source> dans mon persistence.xml
• inject/affecter votre propre EntityManagerFactory avec Persistence.createEntityManagerFactory("my-persistence-unit-name")