Discussion :

[grunt2000]

Mon EJB 3 déployé, j'ai cherché des outils pratiques pour me permettre de le tester.

L'un d'entre-eux était ejb3Unit, mais il ne soutient pas JUnit 4 (seulement le 3) ce qui me pose des difficultés pour la prévention des timeouts et le rend inéligible.

Quel environnement mettez-vous en place pour tester vos EJB 3?

Un environnement "out of container"? Si oui, lequel? Quelles sont vos expériences?

Lors de vos tests, utilisez-vous la substitution de bases de données que permet souvent l'outil? Utilisez-vous les objets simulacres (mock) pour redéfinir les réponses de vos DAOs ou de vos services?


Je suis face au cas suivant:
(je ne mets pas dedans tout les try-catch qui devraient y figurer pour le code soit compilable. C'est juste une illustration).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
@Stateless public class MonBean
{
       public void accepterAchat(PersonneId id, Commande c)
       {
            IPersonnesDAO daoPersonnes = PersonnesDAOFactory.getInstance();
            Personne p = daoPersonnes.find(id);
 
            ServiceComptabilité compta = ctx.lookup("LaCompta");
 
            if (compta.clientSolvable(p))
            {
                 Grossiste grossiste = ctx.lookup("MonGrossiste");
 
                 if (grossiste.possedeArticles(c.listeArticles()))
                 {
                     ICommandesDAO daoCommandes = CommandesDAOFactory.getInstance();
 
                     if (daoCommande.exist(c.getId()) == false)
                        daoCommande.insert(c);
                 }
            }
       }
}

Admettons que sur ce service je souhaite faire les tests qui suivent, quel serait le meilleur environnement que vous consitueriez pour faciliter leur réalisation?

1) Une personne d'un identifiant donné, on la trouve bien.

2) On donnerait une personne bidon (ici par un daoPersonne simulacre) la compta ne se ferait pas avoir et la repèrerait.

3) Quoi qu'ait dit la compta (ici un service Compta simulacre), le grossiste, lui, arrive toujours à fonctionner dans le cadre de ce service là. (bien entendu, il serait plus habile de tester le service grossiste dans ses tests dédiés. Mais là, on veut le tester dans cette situation).

4) Quand tout est bon, on arrive à insérer une commande en base.

etc.

[cyberskype]

Bonjour,

Peut on faire des tests Unitaires dans le conteneur EJB, Comment peut tester avec Netbeans 6.1 apres avoir generer le tests de sa session bean ou de son entite bean.
Est on oblige d utiliser EntityMangerFactory et Entimanager dans le test a l intereieur du conteneur.

Si on veut le faire en dehors du conteneur ejb avez des tutos a m indiquer ,

Merci a vous

[sebastien.hebert]

En effet, l'écriture de tests pour les EJB 3 n'est pas chose aisée.

Pourtant, on peut s'en sortir en utilisant jboss-ejb3-microcontainer.

Ce dernier permet d'instancier un "conteneur léger" dans une application Java classique qui contient l'ensemble des EJB à tester.

Une autre solution consiste à utiliser Spring et un fichier applicationContext.xml qui contient les définitions des beans pour recrér les services d'un container d'EJB classique - EntityManagerFactory, JPATransactionManager, etc.)

Le dernière solution, de loin la plus simple consiste à déployer ses EJB dans le container, puis d'écrire un test unitaire qui au démarrage, instancie un InitialContext comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
private MonEJBInterfaceRemote service;
 
@BeforeClass
public static void setUpClass() throws Exception {
     Context annuaire = new InitialContext();
     service = (MonEJBInterfaceRemote) annuaire.lookup(MonEJBInterfaceRemote.class.getName());
}
 
@Test
public void unTest() {
     service.maMethodeMetier();
     (...)
}

Bien entendu, il est nécessaire de préciser dans le classpath les propriétés JNDI. Cela peut se faire via l'écriture d'un fichier properties intitulé "jndi.properties" placé dans le package par défaut "Test Packages" de Netbeans.

Ce fichier devra contenir les informations de connexions à l'annuaire JNDI. Par exemple, pour Glassfish ->

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
#Contenu de jndi.properties
 
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs=com.sun.enterprise.naming
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
org.omg.CORBA.ORBInitialHost=IP_DU_SERVEUR_GLASSFISH
org.omg.CORBA.ORBInitialPort=3700  #(valeur par défaut)

De cette manière, on peut tester les EJB déployés en bénéficiant de tous les services du container. Bien entendu, on ne peut faire cela que si les EJB ont une interface Remote avec la balise @Remote

J'allais oublier. Il faut rajouter dans le classpath du projet les références aux jars suivants qui se trouvent dans %GLASSFISH_HOME%/lib :

appserv-deployment-client.jar
appserv-rt.jar
webservices-rt.jar (si tu utilises des services Web Glassfish - projet METRO)
appserv-admin.jar
javaee.jar
toplink-essentials-agent.jar (si tu veux accéder à l'EntityManager directement)
toplink-essentials.jar (si tu veux accéder à l'EntityManager directement)
imqjmsra.jar (si tu veux tester un EJB MDB - ce jar se trouve dans %GLASSFISH_HOME%/lib/install/applications/jmsra)

Voilà, cette dernière solution permet donc de tester tes EJB. Ces derniers doivent être bien entendus déployés dans le container au préalable mais de cette manière, tu es le plus proche d'un environnement de production.

A+

[cyberskype]

C est Limpide, clair et concis, je vais le tester ce soir,
Merci

[cyberskype]

Bonjour, j ai fait le test comme dit,
j ai cree le fichier jndi.properties au package default dans le package test packages du jar
et voila l erreur qui est affichée,

merci d m aider


Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.glci.persistence.facade.GestionEvenementFacadeBeanTest.setUpClass(GestionEvenementFacadeBeanTest.java:43)

[lamoua76]

Peut-être que ton fichier n'est tout simplement pas au bon endroit.

L'exécution se fait souvent à la racine du projet (à voir pour les tests).

Mets plutôt le fichier jndi au niveau de la racine du projet et non dans le package default du package test, on ne sait jamais. Car là effectivement, on dirait que les configuration du JNDI ne sont pas faites.