Comments (0)

Wiser est un petit serveur SMPT facilement intégrable dans une classe de test unitaire (Junit, TestNg, etc.). Il réceptionne les messages et les sauvegardes dans un tableau au lieu de les envoyer sur le réseau. Ces messages sont ensuite disponibles pour vérification.

Avec ce serveur, il est possible de vérifier tous les types de mails même ceux qui contiennent des pièces jointes. Il est développé dans le projet subethasmtp.

Dans un projet maven il est nécessaire d’ajouter les dépendances suivantes :

<dependency>
    <groupId>org.subethamail</groupId>
    <artifactId>subethasmtp-wiser</artifactId>
    <version>1.2</version>
    <scope>test</scope>
</dependency>

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8.2</version>
    <scope>test</scope>
</dependency>

Il faut, ensuite, écrire une méthode qui va envoyer un email et la tester dans une classe JUnit. Je vous propose d’utiliser JavaMail. Remarque : vous pouvez aussi envoyer un email à partir d’un logiciel comme thunderbird s’il est configuré avec Wiser comme serveur SMTP.

 /**
  * Méthode qui envoie un email.
  */
public void sendEmail(String serveur, int port) throws AddressException, MessagingException {
   Properties prop = System.getProperties();
   prop.put("mail.smtp.host", serveur);
   prop.put("mail.smtp.port", String.valueOf(port));

   Session session = Session.getDefaultInstance(prop,null);
   InternetAddress[] internetAddresses =
   new InternetAddress[] {new InternetAddress("toi@xxx.com")};

   Message message = new MimeMessage(session);
   message.setFrom(new InternetAddress("moi@xxx.com"));
   message.setRecipients(Message.RecipientType.TO, internetAddresses);
   message.setSubject("Test");
   message.setText("test mail");

   Transport.send(message);
 }

 /**
 * Démarrage de Wiser avant l'éxécution du test.
 */
 @Before
 public void setUp() {
   wiser = new Wiser();
   wiser.setPort(2500); // port par défaut : 25
   wiser.start();
 }

 @After
 public void tearDown() {
   wiser.stop();
 }

 @Test
 public void testSendEmail() {
   try {
     sendEmail("localhost", 2500);   // Appel de la méthode qui envoie l'email.
     assertEquals(1, wiser.getMessages().size());

     for (WiserMessage message : wiser.getMessages()) {
       String envelopeSender = message.getEnvelopeSender();
       String envelopeReceiver = message.getEnvelopeReceiver();

       MimeMessage mess = message.getMimeMessage();

       // Il ne reste plus qu'a vérifier le contenu de l'email.
     }

   } catch (Exception e) {
     fail();
   }
 }

Vous pouvez retrouver mon projet exemple ici.

Dans la distribution de subethasmtp, vous retrouverez des exemples pour tester des emails plus compliqués avec notament des pièces jointes.

Comments (3)

JBoss propose un certain nombre d’archetypes dont un qui génère  une application J2EE6 pour JBoss 7 : org.jboss.spec.archetypes:jboss-javaee6-webapp. Or, par défaut, maven ne connait pas cet archetype. Voici comment réussir à l’utiliser dans Eclipse.

Avant toute chose, il faut vérifier que maven est configuré pour aller chercher des librairies sur le repository JBoss : le fichier settings.xml (~/.m2/settings.xml ou $MAVEN_HOME/conf/settings.xml) doit contenir le code XML suivant :

<settings>
 ...
  <profiles>
    ...
    <profile>
      <id>jboss-public-repository</id>
      <repositories>
        <repository>
          <id>jboss-public-repository-group</id>
          <name>JBoss Public Maven Repository Group</name>
          <url>https://repository.jboss.org/nexus/content/groups/public-jboss/</url>
          <layout>default</layout>
          <releases>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </releases>
          <snapshots>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>jboss-public-repository-group</id>
          <name>JBoss Public Maven Repository Group</name>
          <url>https://repository.jboss.org/nexus/content/groups/public-jboss/</url>
          <layout>default</layout>
          <releases>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </releases>
          <snapshots>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>

  </profiles>

  <activeProfiles>
    <activeProfile>jboss-public-repository</activeProfile>
  </activeProfiles>
  ...
</settings>

Ensuite, pour créer le projet dans Eclipse, il faut commencer par installer le catalogue JBoss : Windows -> Preferences… puis dans la fenêtre Maven -> Achetypes cliquer sur le bouton  Add Remote Catalog… Saisir https://repository.jboss.org/nexus/content/groups/public/archetype-catalog.xml dans l’intitulé Catalogue File et JBoss dans Description. Après l’opération, il ne reste plus qu’à accéder au wizard de création d’un projet Maven (File -> New -> Project… puis Maven project) et de sélectionner l’archetype jboss-javaee6-webapp.

Le squelette de l’application est celui-ci :

/home/…/jboss-webapp-j2ee6
|– pom.xml
|– readme.html
|– readme.md
`– src
|– main
|   |– java
|   |   `– test
|   |       `– jboss_webapp_j2ee6
|   |           |– controller
|   |           |   `– MemberRegistration.java
|   |           |– data
|   |           |   `– MemberListProducer.java
|   |           |– model
|   |           |   `– Member.java
|   |           |– rest
|   |           |   |– JaxRsActivator.java
|   |           |   `– MemberResourceRESTService.java
|   |           `– util
|   |               `– Resources.java
|   |– resources
|   |   |– import.sql
|   |   `– META-INF
|   |       `– persistence.xml
|   `– webapp
|       |– index.html
|       |– index.xhtml
|       |– resources
|       |   |– css
|       |   |   `– screen.css
|       |   `– gfx
|       |       |– banner.png
|       |       `– logo.png
|       `– WEB-INF
|           |– beans.xml
|           |– faces-config.xml
|           `– templates
|               `– default.xhtml
`– test
|– java
|   `– test
|       `– jboss_webapp_j2ee6
|           `– test
|               `– MemberRegistrationTest.java
`– resources
`– arquillian.xml

Ce qui équivaut à une application de départ avec un exemple JSF2 s’appuyant sur une base de données embarquée avec quelques classes constituant un modèle MVC, un exemple de service web REST, et un exemple de test unitaire avec Arquillian. A noter aussi, l’utilisation d’un EJB3 archivé dans un WAR et non un EAR comme il aurait fallu le faire avec J2EE5.

Pour déployer l’application il faut la packager et utiliser le plugin JBoss de déploiement déjà configuré par l’archetype (maven package jboss-as:deploy). Attention, pour que tout se déroule correctement, il faudra avoir démarré votre serveur JBoss7 au préalable.

Comments (0)

Il y a quelques mois, on m’a fait découvrir le plugin eclipse MoreUnit. Comme je le trouve très pratique, je profite de mon blog pour en parler. Il permet de gagner du temps pour le développement et l’exécution des tests unitaires. Il facilite aussi l’association entre les classes destinées à l’exécution et celles qui vont les tester. Ce plugin est disponible sur le marketplace.

Si l’option Decorate Classes with Test Case est activée (Window > Preferences… > General > Appearance > Label Decorations), les classes qui sont testées sont représentées avec un icon différent :

La même marque verte apparaît au niveau de la marge de l’éditeur Java au début des méthodes testées :

A partir d’une classe, un menu contextuel permet les actions suivantes :

• Ouvrir la classe de test associée
• Générer la classe de test si celle-ci n’existe pas
• Exécuter la classe de test en entier
• Exécuter les méthodes de test associées à une sélection de méthodes de la classe d’origine

Le plugin sait aussi prendre en compte les refactorings de la classe testée :

• Si la classe testée est renommée, la classe de test est renommé elle aussi
• Idem, si la méthode testée est renommée, les méthodes de test le sont aussi
• Si la classe testée change de package, la classe de test change aussi de package

Enfin, la dernière fonctionnalité que je trouve très utile dans certains contextes, MoreUnit peut générer les mocks des objets utilisés dans la classe testée. Il est compatible avec Mockito et EasyMock. Il ne reste plus qu’a les paraméter.

Comments (0)

Comment savoir si une méthode développée fonctionne bien dans un contexte multithread ? Pour répondre à cette question je vous propose cet exemple qui se base sur une classe simple utilisant une instance  statique de SimpleDateFormat qui n’est pas un objet threadsafe. Cette classe possède deux méthodes l’une n’est pas threadsafe l’autre l’est grâce à un bloc “synchronisé”.

public class DateUtil {
 /** Static pour bénéficier d'une instance partagée par l'ensemble des threads.*/
 private static DateFormat df = new SimpleDateFormat("dd/MM/yyyy");

 public static Date parse(String date) throws ParseException {
   Date result = null;
   result = df.parse(date);
   return result;
 }

 public static Date parseThreadSafe(String date) throws ParseException {
   Date result = null;
   // Ce bloc garantit que la méthode fonctionne en multithread.
   synchronized (df) {
     result = df.parse(date);
   }
   return result;
 }
}

La classe de test utilise la librairie TestNg et non JUnit car cette dernière ne propose pas de support du multithread. De son coté, TestNg permet de paramétrer une méthode de test avec, entre autre, deux paramètres :

• invocationCount : le nombre d’invocation de la méthode (valeur par défaut : 1)
• threadPoolSize : la taille du pool de threads qui vont exécuter la méthode (valeur par défaut : 0)

public class DateUtilTest {

 @Test(threadPoolSize=20, invocationCount=100)
 public void testParse() {
   try {
     for (int i = 10; i < 20; i++) {
       assertEquals(new SimpleDateFormat("dd/MM/yyyy").parse("01/01/20" + i),
         DateUtil.parse("01/01/20" + i));    
     }
   } catch (ParseException e) {
     fail("TEST KO : " + e.getMessage());
   }
 }

 @Test(threadPoolSize=20, invocationCount=100)
 public void testParseThreadSafe() {
   try {
     for (int i = 10; i < 20; i++) {
       assertEquals(new SimpleDateFormat("dd/MM/yyyy").parse("01/01/20" + i),
         DateUtil.parseThreadSafe("01/01/20" + i));    
     }
   } catch (ParseException e) {
     fail("TEST KO : " + e.getMessage());
   }
 }

}

Les boucles for servent à augmenter la probabilité d’appel simultanés des méthodes testées. Le résultat de l’exécution est assez simple a analyser car les seules méthodes qui tombent en erreur sont celles qui exécutent la méthode sans le bloc synchronisé.

Vous pouvez retrouver le projet maven à l’adresse suivante : https://subversion.assembla.com/svn/everythingiswrong/multithread-tests

Comments (0)

L’intégration des tests unitaires SeamTest dans un projet Maven est assez compliquée. Voici un exemple concret :

Présentation du projet

Avant de rentrer dans des détails techniques, je préfère vous parler de l’application qui va me servir de base pour intégrer mon test SeamTest.

Vision fonctionnelle

J’ai choisi de me baser sur l’exemple “hello world” du livre Seam Framework: Experience the Evolution of Java EE 2nd edition. Vous pouvez retrouver les sources des exemples du livre à l’adresse suivante : http://solutionsfit.com/blog/books/. Malheureusement, l’auteur utilise Ant et non Maven pour gérer la compilation de ses projets.

J’ai rajouté l’utilisation d’un service EJB Stateless pour démontrer la possibilité d’utiliser SeamTest dans un contexte technique hétérogène. Voici le diagramme des cas d’utilisation de l’application :

Vision maven

Le projet est composé d’un module père ayant trois modules fils :

seamtest-parent
|– seamtest-ear
|– seamtest-ejb
`– seamtest-webapp

Vous pouvez checkouter les sources à l’adresse suivante : https://subversion.assembla.com/svn/everythingiswrong/seamtest-parent/.

Dans le reste de l’article, je vais me focaliser sur le module seamtest-ejb car c’est lui qui contient le composant Seam, la persistance et l’EJB Stateless à tester.

Composant Seam à tester

Nous allons tester le composant qui va :

• Enregistrer une nouvelle personne dans la base de données
• Rechercher toutes les personnes de la base de données

@Stateful
@Name("manager")
public class ManagerAction extends Manager {
  @In
  private Person person;

  @Out
  private List<Person> fans;

  @EJB
  private CalculService calculService;

  @PersistenceContext
  private EntityManager em;

  //Méthode à tester.
  public void sayHello () {
    em.persist (person);
    fans = em.createQuery("select p from Person p").getResultList();
  }

  // Méthode pour vérifier l'injection de l'EJB Stateless dans le composant Seam
  public int additionner(int a, int b) {
    return (int) calculService.addition(a, b);
  }

  @Remove
  @Destroy
  public void destroy() {
  }
}

Installation et configuration

Pour information, SeamTest utilise le serveur JBoss embedded.

Installation de JBoss Embedded

Cette installation se résume à la copie du répertoire booststrap qui est dans la distribution de Seam (par exemple ici) dans le répertoire src/test.

Le fichier “pom.xml”

Ce fichier doit contenir l’ensemble des librairies qui vont permettre de démarrer et d’exécuter le serveur JBoss embedded. Il doit aussi prendre en compte le répertoire de bootstrap ajouté précédemment dans les ressources des tests.

<dependencies>
  ...
  <!-- dépendances des tests unitaites : http://community.jboss.org/thread/18299 -->
  <!-- dependencies related to JBoss Embedded for Seam 2.X.X -->
  <dependency>
    <groupId>org.jboss.seam.embedded</groupId>
    <artifactId>jboss-embedded-all</artifactId>
    <version>beta3.SP12</version>
    <scope>test</scope>
    <exclusions>
      <exclusion>
        <groupId>org.jboss.microcontainer</groupId>
        <artifactId>jboss-deployers-client-spi</artifactId>
      </exclusion>
      <exclusion>
        <groupId>org.jboss.microcontainer</groupId>
        <artifactId>jboss-deployers-core-spi</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
  <dependency>
    <groupId>org.jboss.seam.embedded</groupId>
    <artifactId>hibernate-all</artifactId>
    <version>beta3.SP12</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.jboss.seam.embedded</groupId>
    <artifactId>thirdparty-all</artifactId>
    <version>beta3.SP12</version>
    <scope>test</scope>
  </dependency>

  <!-- dependencies related to JBoss MicroContainer -->
  <!-- java.lang.NoClassDefFoundError: javax/faces/application/Application -->
  <dependency>
    <groupId>javax.faces</groupId>
    <artifactId>jsf-api</artifactId>
    <version>1.2_09</version>
    <scope>test</scope>
  </dependency>

  <!-- java.lang.NoClassDefFoundError: org/jboss/el/ExpressionFactoryImpl -->
  <dependency>
    <groupId>org.jboss.el</groupId>
    <artifactId>jboss-el</artifactId>
    <version>1.0_02.CR4</version>    <!-- http://seamframework.org/Community/IllegalAccessErrorAfterUpgradingTo212CR1 -->
    <scope>test</scope>
  </dependency>

  <!-- dependencies related to TestNG -->
  <dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>5.8</version>
    <classifier>jdk15</classifier>
    <scope>test</scope>
  </dependency>
</dependencies>
<build>
  <testResources>
    <testResource>
      <directory>src/test/resources</directory>
      <filtering>true</filtering>
    </testResource>
    <testResource>
      <directory>src/test/bootstrap</directory>
      <filtering>false</filtering>
    </testResource>
    <testResource>
      <directory>src/test/bootstrap</directory>
      <filtering>true</filtering>
      <includes>
        <include>**/*.xml</include>
      </includes>
    </testResource>
  </testResources>
  ...
</build>

Remarque : à l’heure actuelle la version la plus récente du conteneur est la beta3.SP12.

Fichiers de tests

Dans la pratique, on ajoute toujours un fichier seam.properties vide dans le classpath des jar contenant des composants Seam. Dans le cas du test, ce fichier doit contenenir au minimum l’information sur le nom JNDI des EJB :

org.jboss.seam.core.init.jndiPattern = #{ejbName}/local

La classe de test doit étendre SeamTest. Elle peut ensuite utiliser l’EL pour référencer les composants Seam :

public class ManagerActionTest extends SeamTest {
  private static Logger LOGGER = Logger.getLogger(ManagerActionTest.class);

  @Test
  public void testSayHello() {
    try {
      new ComponentTest() {
        @Override
        protected void testComponents() throws Exception {
          setValue("#{person.name}", "Yan");
          invokeMethod("#{manager.sayHello}");
          List<Person> fans = (List<Person>) getValue("#{fans}");
          assertNotNull(fans);
          assertEquals(1, fans.size());
          assertEquals("Yan", fans.get(0).getName());
          // Test le service EJB
          assertEquals(3, invokeMethod("#{manager.additionner(1, 2)}"));
        }
      }.run();
    } catch (Exception e) {
      LOGGER.error("TEST KO : " + e.getMessage());
      fail("TEST KO : " + e.getMessage());
    }
  }
}

En utilisant Hibernate, vous pouvez exécuter des scripts SQL au déploiement de votre test en ajoutant un fichier import.sql dans le classpath de test (src/test/resources). Cela dit,  dans ce cas, je conseillerai plutôt d’utiliser l’intégration avec DBUnit.

Exécution

Pour exécuter les tests il faut lancer la commande mvn clean test.

Variantes

Intégration avec DBUnit

L’intégration est possible entre seamTest et DBUnit. La classe de test doit étendre DBunitSeamTest et implémenter la méthode prepareDBUnitOperations(). Il faut aussi donner à TestNg la nom JNDI de la source de données vers la base de données ainsi que le type de la base de données (HSQL ou MYSQL). Pour cela, il faut configurer le plugin surefire comme cela :

<build>
  ...
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.4.3</version>
    <configuration>
      <systemProperties>
        <property>
          <name>datasourceJndiName</name>
          <value>java:/DefaultDS</value>
        </property>
        <property>
          <name>database</name>
          <value>HSQL</value>
        </property>
      </systemProperties>
      <argLine>-Dsun.lang.ClassLoader.allowArraySyntax=true</argLine>
    </configuration>
 ...
</build>

Remarque : deux propriétés pour déclarer le type de la source de données et son nom JNDI ainsi qu’un argument pour permettre au serveur JBoss Embedded de s’éxécuter avec une JDK 1.6 (par défaut ce serveur n’est compatible qu’avec une JDK1.5).

Pour information, DBUnit propose deux implémentations différentes pour décrire les données d’une base : le FlatXmlDataSet et le XmlDataSet (http://dbunit.sourceforge.net/components.html).  SeamTest ne support que le FlatXmlDataSet.

Dépendances sur des projets ou modules de type EJB

Dans le cas où votre module dépende d’un autre module EJB, il faut arriver à déployer la dépendance de type EJB dans le conteneur JBoss embedded. Il est possible de faire cette opération avec le plugin maven maven-dependency-plugin comme cela :

<build>
  ...
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
      <execution>
        <id>copy</id>
        <phase>process-test-resources</phase>
        <goals>
          <goal>copy</goal>
        </goals>
        <configuration>
          <artifactItems>
            <artifactItem>
              <groupId>...</groupId>
              <artifactId>...</artifactId>
              <version>...</version>
              <type>...</type>
              <classifier>...</classifier>
              <overWrite>false</overWrite>
              <outputDirectory>${project.build.directory}/test-classes/deploy</outputDirectory>
            </artifactItem>
          </artifactItems>
        </configuration>
      </execution>
    </executions>
  </plugin>
  ...
</build>

Remarque : la copie de la dépendance se déroule avant la phase d’exécution des tests.

Comments (2)

Depuis pas mal de temps, je me pose des questions sur les bonnes pratiques à mettre en œuvre dans le développement de mes tests unitaires. N’ayant jamais rencontré de personne ayant beaucoup d’expérience dans le domaine, je me suis toujours restreint à développer des tests :

• Rapides à développer
• Faciles à maintenir
• limités à une fonctionnalité

C’est dans ce contexte que j’ai cherché sur internet des propositions de bonnes pratiques sur les tests unitaires automatisés. J’ai trouvé mieux : des pratiques à éviter (http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/).