• Tu utilises déjà TestNG

   

• Tu as utilisé TestNG par le passé

   

• Tu aimerais bien utiliser TestNG

   

• Tu t’intéresses à TestNG

 
alors ton avis m’intéresse ! Dis-moi quels sont les intérêts que tu lui trouves ? Pourquoi le préfères-tu à JUnit, ou au contraire pourquoi préfères-tu JUnit ? Que lui manque-t’il ? Bref, dis moi tout !
 
Merci.

Pour démarrer sur le sujet, vous avez suivi les étapes écrites sur mon post, comme je l’ai fait lors de ma présentation. C’est bien joli tout ça, mais dans la vraie vie réelle, vous n’avez pas un module Maven dédié au code JavaScript. Votre code JavaScript est (bêtement) dans votre application web ! Du coup, vous vous posez des questions sur la façon de procéder, en particulier concernant les analyses Sonar…

Allez zou, suivez le guide !

Zou, créons un projet

Lors de ma présentation, j’ai utilisé l’archetype Maven de.akquinet.javascript.archetypes:javascript-quickstart, qui crée un squelette d’application contenant juste du JavaScript.
Cette fois-ci, on va partir d’un projet web classique dans lequel on incluera notre code JavaScript. Donc quelque chose de plus proche que ce que vous avez sur votre projet !

Je pars donc avec l’archetype org.codehaus.mojo.archetypes:webapp-javaee6 pour avoir un squelette d’application web. Il s’agit là de votre propre projet web… De mon côté, j’y ajoute une petite classe Java, ainsi qu’une class de test JUnit pour le fun.

Désormais, on peut lancer une première analyse Sonar, avec la commande mvn clean install sonar:sonar.

Jusqu'ici, tout va bien !

Maintenant, je rajoute mon code JavaScript (les fichiers underscore.js et undescore-test.js). Je les positionne respectivement dans les répertoires src/main/javascript et src/test/javascript. Il est possible d’adapter ces répertoires, bien entendu !
On ajoute le fichier de configuration de jsTestDriver.conf qui va nous permettre de lancer nos tests JavaScript de Jasmine. On ajoute aussi dans un coin (le répertoire lib/ disons) :

• le fichier jasmine.js ;
• le fichier jasmineAdapter.js (pour lancer les tests JavaScript écrits en Jasmine avec js-test-driver) ;
• la librairie coverage-1.3.4.b.jar, qui est le plugin de calcul de couverture du code JavaScript pour js-test-driver.

Au final, la structure de mon projet a la tête suivante :

chouchoutage (oui, c'est le nom pourri de mon projet)
  + pom.xml
  ` src
      + lib
      |   ` coverage-1.3.4.b.jar
      |   ` jasmine.js
      |   ` jasmineAdapter.js
      + main
      |   + java
      |   |   ` ze-code-java
      |   ` javascript
      |       ` underscore.js
      + test
      |   + java
      |   |   ` test-unitaires
      |   ` javascript
      |       ` underscore-test.js
      ` webapp
          ` toute-la-partie-web

Si vous souhaitez plus d’informations sur cette étape (comme le contenu du fichier jsTestDriver.conf par exemple), allez jeter un oeil sur mon post décrivant ma session Devoxx.

Voilà, on arrive à quelque chose qui ressemble en gros à votre projet. Maintenant, on va voir comment on va pouvoir exécuter nos codes JavaScript, et en faire l’analyse Sonar.

Ne tombons pas dans les poms !

Attaquons nous au problème principal : la modification du pom. Nous allons d’abord l’adapter pour exécuter nos tests JavaScript. Nous verrons ensuite pour l’analyse Sonar…

Ajoutons d’abord la dépendance suivante :

    <dependency>
        <groupId>com.googlecode.jstd-maven-plugin</groupId>
        <artifactId>jstd-maven-plugin</artifactId>
        <version>1.3.2.5</version>
        <scope>test</scope>
    </dependency>

On ajoute ensuite le plugin de jstd-maven-plugin :

    <plugin>
        <groupId>com.googlecode.jstd-maven-plugin</groupId>
        <artifactId>jstd-maven-plugin</artifactId>
        <version>1.3.2.5</version>
        <configuration>
            <port>9876</port>
            <!-- A adapter ! -->
            <browser>/Applications/Firefox.app/Contents/MacOS/firefox-bin</browser>
            <tests>all</tests>
            <config>jsTestDriver.conf</config>
            <testOutput>target/jstestdriver</testOutput>
        </configuration>
        <executions>
            <execution>
                <id>run-tests</id>
                <goals>
                    <goal>test</goal>
                </goals>
            </execution>
        </executions>
    </plugin>

Dernier point, nous ajoutons le repository contenant les plugins sus-cités :

    <repositories>
          <repository>
              <id>jstd-maven-plugin google code repo</id>
              <url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url>
          </repository>
    </repositories>
    <pluginRepositories>
          <pluginRepository>
              <id>jstd-maven-plugin google code repo</id>
              <url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url>
          </pluginRepository>
    </pluginRepositories>

Voilà, nous pouvons vérifier si cela fonctionne. La commande mvn clean install va nous le dire :

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running fr.linsolas.WorldTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] --- jstd-maven-plugin:1.3.2.5:test (run-tests) @ chouchoutage ---

-------------------------------------------
 J S  T E S T  D R I V E R
-------------------------------------------

Firefox: Runner reset.
................
Total 16 tests (Passed: 16; Fails: 0; Errors: 0) (10,00 ms)
  Firefox 9.0.1 Mac OS: Run 16 tests (Passed: 16; Fails: 0; Errors 0) (10,00 ms)

C’est plutôt une bonne nouvelle ça ! Surefire a lancé mon test JUnit (fr.linsolas.WorldTest), puis, dans un second temps, a exécuté les tests de js-test-driver.

Plongeons dans l’analyse Sonar

Et bien voilà, il ne nous reste plus qu’à exécuter une analyse Sonar et le tour est joué… Mais ce n’est pas si simple en fait !
Sonar permet bien d’analyser un projet Java, il permet d’analyser également un projet JavaScript, mais hélas pas en même temps !
Nous allons devoir donc lancer deux analyses Sonar pour arriver à nos fins.

Etant donné que nous ne voulons pouvoir lancer avec le même pom.xml l’analyse Sonar pour le code Java et l’analyse Sonar pour le code JavaScript, nous allons créer un profil Maven qui sera dédié à l’analyse JavaScript :

    <profiles>
        <profile>
            <id>js</id>
            <properties>
                <sonar.language>js</sonar.language>
                <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
            </properties>
        </profile>
    </profiles>

Voyons voir si cela fonctionne. Lançons une première analyse avec mvn clean install sonar:sonar. En exécutant cette commande, l’analyse Sonar ne montre aucune différence avec celle réalisée plus tôt. Normal, me direz-vous, on reste sur l’analyse Java.
Lançant maintenant la même commande, mais en activant le profile js : mvn -Pjs clean install sonar:sonar. Le résultat n’est pas celui attendu :

Ooooups

Houlà, mais on a tout cassé ! On n’obtient plus aucun chiffre, ni rien Le problème vient simplement du fait que le plugin JavaScript pour Sonar va chercher les sources dans le répertoire src/main/java au lieu de src/main/javascript.
Il faut donc lui spécifier ce nouveau répertoire. On va donc spécifier un sourceDirectory dans notre profile js. Du moins on aimerait bien, car hélas Maven n’autorise pas que l’on redéfinisse ce répertoire dans un profil ! C’est étrange, mais c’est comme ça. Enfin pas tant que ça, car Maven – par défaut – n’accepte qu’un seul chemin de sources. Comme plusieurs profiles peuvent être actifs en même temps, on pourrait bidouiller les profiles pour avoir ainsi plusieurs répertoires de sources. On s’égare un peu là…
Nous pourrions passer par le plugin build-helper qui permet de spécifier plusieurs répertoires de sources. Je n’en ferais rien, je vais « simplement » fourvoyer Maven en jouant avec les propriétés :

    <properties>
        <source.dir>src/main/java</source.dir>
        <test.source.dir>src/test/java</test.source.dir>
    </properties>

    <build>
        <sourceDirectory>${source.dir}</sourceDirectory>
        <testSourceDirectory>${test.source.dir}</testSourceDirectory>
        ...
    </build>

    <profiles>
        <profile>
            <id>js</id>
            <properties>
                <source.dir>src/main/javascript</source.dir>
                <test.source.dir>src/test/javascript</test.source.dir>
                ...

Voilà, Maven n’y voit que du feu, et moi j’ai réussi à me débrouiller (à bidouiller disons plutôt).

Alors, que donne l’analyse Sonar maintenant ?

Voilà qui est mieux !

OUI ! Enfin, nous réussissons à obtenir notre belle analyse du code JavaScript par Sonar !

Et voilà, c’est fini.
Vraiment ? Non !
Un dernier souci se pose : si je lance l’analyse Java, j’ai un beau rapport Sonar. Mais dès que je lance l’analyse JavaScript, mon rapport JavaScript efface celui de Java !
Il faut donc trouver un moyen de faire cohabiter les deux. Je propose simplement de profiter de l’option sonar.branch pour différencier les deux projets. On ajoute donc dans le profil js :

    <profiles>
        <profile>
            <id>js</id>
            <properties>
                <sonar.branch>javascript</sonar.branch>
                ...

Cette fois-ci, on relance les deux analyses : mvn clean install sonar:sonar puis mvn -Pjs clean install sonar:sonar.
Une fois les deux commandes terminées, nous nous retrouvons avec non plus un mais deux projets Sonar :

Les deux font la paire

Chacun de ces projets est adapté à son langage, le premier pour Java, le second pour JavaScript.

Et voilà, c’est fini.
Vraiment ? Cette fois, oui

N’hésitez pas à faire part, dans les commentaires, de vos propres expériences, ou propositions d’améliorations !

Start Slide Show with PicLens Lite

Ayant eu l’occasion de me remettre sur Play! ces derniers jours, je ne peux m’empêcher de vous faire partager le plaisir que j’ai eu à l’utiliser en vous parlant d’un aspect sympathique de ce framework : la gestion des entités.

Si vous avez déjà eu l’occasion de vous faire la main sur Play!, vous ne devriez rien apprendre ici. Il s’agit surtout de donner envie à ceux qui hésitent à se lancer dans l’aventure Play!.

L’entité User

Commençons par écrire notre entité, que nous appellerons User. Voici le code :

package models;

import javax.persistence.Entity;
import play.db.jpa.Model;

@Entity
public class User extends Model {

    public String name;
    public String email;
    public boolean isAdmin;

    public User() {
    }

    public User(String name, String email, boolean isAdmin) {
        this.name = name;
        this.email = email;
        this.isAdmin = isAdmin;
    }

}

Nous notons déjà deux choses importantes :

• Les propriétés de notre entité sont publiques, et nous ne polluons plus notre classe avec des getters et setters (en attendant les property de Java 8 ).
• L’entité étend la classe play.db.jpa.Model. C’est ce point que nous allons voir en détail juste après.

La super-classe Model

Cette super-classe Model (et ses parents) vont nous simplifier grandement la vie, car elle nous évitera l’écriture d’un DAO. En effet, nous disposons, simplement grâce à notre entité, des principales méthodes de CRUD (Create, Read, Update, Delete):

• count() pour compter le nombre d’entités, en fournissant éventuellement des paramètres pour affiner la requête ;
• save() pour sauver notre entité ;

Voyons quelques exemples basiques avec un test unitaire :

public class UserTest extends UnitTest {

    @Before
    public void clean() {
        Fixtures.deleteDatabase();
    }

    @Test
    public void testAddition() {
        assertEquals(0, User.count());
        new User("romain linsolas", "romain@example.com", true).save();
        assertEquals(1, User.count());
    }

}

On notera que nous nettoyons la base de données en mémoire avant chaque test, afin de ne pas fausser nos résultats. De plus, notre classe JUnit étendant la classe play.test.UnitTest afin de profiter de l'environnement de Play! : création de la base de données en mémoire et la structure des tables, par exemple.

    private void insertUsers() {
        new User("romain linsolas", "admin@example.com", true).save();
        new User("romain linsolas", "romain@example.com", false).save();
        new User("bob l'eponge", "bob.leponge@example.com", false).save();
        new User("romain gary", "romain.gary@example.com", false).save();
    }

    @Test
    public void testFindAll() {
        insertUsers();
        assertEquals(4, User.findAll().size());
    }

    @Test
    public void testFindOneArg() {
        insertUsers();
        List<User> list = User.find("byName", "romain linsolas").fetch();
        assertEquals(2, list.size());
        assertEquals("romain linsolas", list.get(0).name);
    }

    @Test
    public void testFindTwoArgs() {
        insertUsers();
        List<User> list = User.find("byNameAndIsAdmin", "romain linsolas", true).fetch();
        assertEquals(1, list.size());
        assertTrue(list.get(0).isAdmin);
    }

Dans le code précédent, nous insérons quatre utilisateurs, et nous vérifions que la méthode findAll() nous retourne le nombre correct d'éléments. Nous faisons également une autre vérification, où nous recherchons tous les utilisateurs selon la valeur d'une propriété, ici name. Le dernier test permet de montrer une utilisation un peu plus poussée de la méthode find("…"), où nous cherchons tous les utilisateurs ayant un nom donné et dont l'attribut isAdmin vaut true.

Nous pouvons encore améliorer les choses en fournissant encore plus de détails sur la recherche, par exemple comme ceci :

    @Test
    public void testFindAndOrder() {
        insertUsers();
        List<User> list = User.find("name = ? order by email desc", "romain linsolas").fetch();
        assertEquals(2, list.size());
        assertFalse(list.get(0).isAdmin);
    }

où nous cherchons les utilisateurs selon un nom donné, puis en les triant selon l'adresse mail. Nous aurions pu encore corsé les choses en mettant en place des jointures avec d'autres entités...

Bien entendu, cette fonctionnalité ne marche pas seulement avec les méthodes de comptage ou de recherche, on pourra l'utiliser avec la méthode delete() :

    @Test
    public void testDelete() {
        insertUsers();
        User.delete("name = ?", "romain linsolas");
        assertEquals(2, User.count());
    }

Ce ne sont là que quelques possibilités, la classe Model offre d'autres fonctionnalités permettant les opérations de CRUD.

Conclusion

Au final, il n'y rien de révolutionnaire ici, mais que de temps gagné grâce à ces méthodes si utiles ! C'est sans doute ça la force première de Play! : nous offrir un retour rafraichissant à la simplicité. Et ça, c'est bon !

Pour aller plus loin :

• Site de Play!
• Tutoriel que j'ai traduit en français sur Play!
• Les entités JPA de Play!

Start Slide Show with PicLens Lite

Contexte

Dans mon exemple, je me baserais sur les outils suivants : Sonar 2.8, Maven 2.2.1, Java 1.6.

Au sein de l’un de mes projets, je dispose de quelques rares tests unitaires, qui couvre environ 7% de l’application. C’est peu. Très peu. Trop peu même.
Mais nous avons également des tests d’intégration.
En gros, ces tests d’intégration vont exécuter un jeu d’environ 300 fichiers d’entrée, qui seront ensuite analysés par mon application.

Mon but est donc de connaître, en plus de ma couverture de test par les tests JUnit, la couverture du code exécuté par mes tests d’intégration.

La structure de mon projet ressemble en gros à ceci :

mon-projet
  +- pom.xml (ce pom-là n'est qu'un pom d'aggrégation)
  +- parent
  |   +- pom.xml (c'est le vrai parent de tous les autres modules)
  +- module-1
  |   +- pom.xml
  +- module-2
  |   +- pom.xml
  +- ...
  +- module-tests
      +- pom.xml
      +- src/test/java/
          +- foo/bar/IntegrationTestsRunner.java

module-tests est un module ne contenant que quelques classes de tests, en particulier IntegrationTestsRunner.java dont le but est d’aller lire mes fichiers de tests, et les exécuter.

Afin de ne pas lancer ces tests d’intégration à chaque build, nous définissons un profil Maven dans le pom.xml de module-tests, comme suit :

    <profiles>
        <profile>
            <id>run-it</id>
            <activation>
                <property>
                    <name>runIT</name>
                    <value>true</value>
                </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                            <includes>
                                <include>**/IntegrationTestRunner.java</include>
                            </includes>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

Ce profil sera activé soit en ajoutant -DrunIT=true soit -Prun-it dans la ligne de commande Maven.

Avec une méthode « traditionnelle », c’est-à-dire l’exécution de tests unitaires via Surefire, aucune couverture de code ne sera détectée, car le code exécuté par les tests d’intégration l’est sur les autres modules du projet. Or Cobertura ne va instrumentaliser que les classes du module courant et non les dépendances (i.e. module-1, module-2, etc.).

Mise en place de JaCoCo

Pour résoudre mon problème, je vais faire appel à JaCoCo, un outil de couverture de test plus performant que Cobertura. Son principal avantage est de pouvoir instrumentaliser les classes au runtime. Dans mon cas présent, JaCoCo va donc pouvoir vérifier la couverture du code sur les différents modules au moment où l’on exécute module-tests.

Avant toute chose, il va nous falloir configurer un peu notre environnement :

• Installer le plugin JaCoCo pour Sonar (à copier dans le répertoire extensions/plugins de son installation Sonar).
• Une fois Sonar redémarré, penser à ajouter dans le dashboard le widget IT Coverage Widget (il faudra sans doute pour cela être connecté en tant qu’administrateur).
• Télécharger l’agent JaCoCo. Pour cela, il faut récupérer le ZIP de JaCoCo ici, l’agent se trouvant alors dans lib/jacocoagent.jar.

Maintenant que ceci est en place, nous allons devoir indiquer à Surefire d’utiliser un agent Java spécifique (l’agent JaCoCo).
Etant donné que nous n’avons besoin de cet agent qu’au moment de l’exécution des tests d’intégration, nous le définirons que pour le profil run-it.
Au sein du pom.xml parent, j’ai donc ajouté :

    <profiles>
        <!-- Profile used to run Integration Tests. In such case, we add the Java agent for JaCoCo... -->
        <profile>
            <id>run-it</id>
            <activation>
                <property>
                    <name>runIT</name>
                    <value>true</value>
                </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                            <argLine>-javaagent:${jacoco.agent.path}=destfile=${jacoco.file.path}</argLine>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

J’ai défini mon profil deux fois, dans le pom.xml parent et dans celui de module-tests. Nous aurions pu tout mettre dans le parent.

Execution

Nous allons avoir besoin d’exécuter maintenant deux commandes Maven :

• mvn clean install -DrunIT=true -Djacoco.agent.path=C:\dev\jacocoagent.jar -Djacoco.file.path=C:\dev\monprojet\jacoco.exec
• mvn -Dsonar.jacoco.itReportPath=C:\dev\monprojet\jacoco.exec sonar:sonar

La première ligne va activer le profil run-it, ce qui aura pour conséquence de lancer le tests d’intégration.
On y définit les deux paramètres (jacoco.agent.path et jacoco.file.path) qui seront passés à Surefire pour définir un agent Java.

La seconde ligne va simplement exécuter l’analyse Sonar sur mon projet, mais en définissant le paramètre sonar.jacoco.itReportPath (généré lors de la première commande), cette analyse comprendra également la couverture des tests d’intégration.

Une fois les deux commandes exécutées, il suffit de se rendre sur son serveur Sonar pour apprécier cette nouvelle mesure de couverture de code !

Comme le montre les captures d’écran sur le post du blog de Sonar à ce sujet, il est possible, à l’instar de la couverture de code, de visualiser la couverture de code de tests d’intégration directement dans la fenêtre de visualisation du code source d’une classe.

Start Slide Show with PicLens Lite

For some reasons, I wanted to categorize my JUnit tests, in order to run only a subset of them.
But this is not as simple as it seems…

Context

In one of my projects, I have many unit tests. It appears that many of them are not unit at all.
Some of them require a real Oracle connection, some others need to load a complex Spring context…

My goal is to split these tests into several categories.

To ease the explanations, I will only consider the two following categories: @FastTest and @SlowTest.

Possible solutions

JUnit introduced recently, in version 4.8, the @Category annotation (see the changelog and also an example here).
The principle is to annotate a class (or a method) with @Category, and then to define the category on which it belongs. For my needs, I could write:

// Interfaces that define my test categories
public interface FastTest { }
public interface SlowTest { }

@Category(SlowTest.class)
public class ASlowTest {
    @Test
    public void foo() { ... }
}

@Category(FastTest.class)
public class ARealUnitTest {
    @Test
    public void foo() { ... }
}

This seems pretty good. But if we go into the details, in order to run all the tests that belong to a specific category, I have to write:

@RunWith(Categories.class)
@IncludeCategory(FastTest.class)
@SuiteClasses( { ARealUnitTest.class, AnotherRealUnitTest.class })
public class FastTestsSuite { }

Here comes the problem: I have to create a Suite (using the annotation @SuiteClasses) to define the classes that should be executed.
That means I have to maintain a list of all the tests for a given Suite. The omissions are therefore likely to be frequent…

Not using JUnit Suite?

How to solve this problem? Here are some ideas:

• Write the JUnit Suite manually as I just explained before, but I may forget to maintain them…
• Let a Maven plugin creates the Suite. I wrote such a plugin some years ago, and I can reuse it now. However, I need to define when this plugin should be executed. Indeed, as the purpose of this plugin is to create or modify Java classes, I can’t run it automatically or anytime. Moreover, it is possible that some classes should not be included in these suites. So this solution will not be considered here.
• Use specific patterns for the filenames of the test classes. For example, the fast tests will be named **FastTest.java, while the other ones will be named **SlowTest.java. Then, I will configure Maven, and some profiles, to use the correct pattern regarding which kind of tests category I want to run. I will not consider this solution neither, as this may also lead to errors.
• Use TestNG instead of JUnit. TestNG is another test framework, which provides some advanced features. One of them is the definition of groups that would be perfect for our needs, especially since Surefire (the test plugin for Maven) natively supports them. This is maybe the best solution for our current concern, but I want to keep JUnit, so, again, I will ignore this idea.
• Modify the Surefire plugin (or why not JUnit directly?) in order to manage the @Category without having to define a Suite. However, this is not a good idea to modify these libraries…

So none of these ideas seems to be helpful…

The last idea: Using JUnit Suite!

The solution I will explain now is based on JUnit Suite. However, these suites will define dynamically the test classes that should be run.
This Suite will look into the classpath for all the classes that are annotated with a particular annotation.

During my searches, I found a project called classpathSuite. One of the purpose of this project is to build a Suite by looking into the ClassPath for some specific classes. Exactly what I want to do!

Using this library, I write the following classes:

@RunWith(Categories.class)
@Categories.IncludeCategory(FastTest.class)
@Suite.SuiteClasses( { AllTests.class })
public class FastTestsSuite {
}

@RunWith(ClasspathSuite.class)
public class AllTests {
}

and classpathSuite will find all the classes in the ClassPath that belong to the category FastTest.
Nice! But this seems to work only when I run my tests in Eclipse, not in a Maven context Or did I miss something?

So I have to re-implement this feature, but that will work with Maven!

The solution

First step: I create two simple annotations, @FastTest and @SlowTest.
They will be used to annotate my JUnit test classes. Note that my solution will only allow you to categorize an entire class, not a method. These annotations will be a replacement for @Category(FastTest.class) and @Category(SlowTest.class).

Now, I create a utility class that will look into the classpath and find the list of classes that are annotated with a specific annotation (@FastTest or @SlowTest in my case) and that belong to a given package (this condition is not technically mandatory, it is just to limit the searches).

On the Java point of view, I get:

public final class ClasspathClassesFinder {

    /**
     * Get the list of classes of a given package name, and that are annotated by a given annotation.
     *
     * @param packageName The package name of the classes.
     * @param testAnnotation The annotation the class should be annotated with.
     * @return The List of classes that matches the requirements.
     */
    public static Class<?>[] getSuiteClasses(String packageName, Class<? extends Annotation> testAnnotation) {
        try {
            return getClasses(packageName, testAnnotation);
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }

    /**
     * Get the list of classes of a given package name, and that are annotated by a given annotation.
     *
     * @param packageName The package name of the classes.
     * @param annotation The annotation the class should be annotated with.
     * @return The List of classes that matches the requirements.
     * @throws ClassNotFoundException If something goes wrong...
     * @throws IOException If something goes wrong...
     */
    private static Class<?>[] getClasses(String packageName, Class<? extends Annotation> annotation) throws ClassNotFoundException, IOException {
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
        String path = packageName.replace('.', '/');
        // Get classpath
        Enumeration<URL> resources = classLoader.getResources(path);
        List<File> dirs = new ArrayList<File>();
        while (resources.hasMoreElements()) {
            URL resource = resources.nextElement();
            dirs.add(new File(resource.getFile()));
        }
        // For each classpath, get the classes.
        ArrayList<Class<?>> classes = new ArrayList<Class<?>>();
        for (File directory : dirs) {
            classes.addAll(findClasses(directory, packageName, annotation));
        }
        return classes.toArray(new Class[classes.size()]);
    }

    /**
     * Find classes, in a given directory (recursively), for a given package name, that are annotated by a given annotation.
     *
     * @param directory The directory where to look for.
     * @param packageName The package name of the classes.
     * @param annotation The annotation the class should be annotated with.
     * @return The List of classes that matches the requirements.
     * @throws ClassNotFoundException If something goes wrong...
     */
    private static List<Class<?>> findClasses(File directory, String packageName, Class<? extends Annotation> annotation)
            throws ClassNotFoundException {
        List<Class<?>> classes = new ArrayList<Class<?>>();
        if (!directory.exists()) {
            return classes;
        }
        File[] files = directory.listFiles();
        for (File file : files) {
            if (file.isDirectory()) {
                classes.addAll(findClasses(file, packageName + "." + file.getName(), annotation));
            } else if (file.getName().endsWith(".class")) {
                // We remove the .class at the end of the filename to get the class name...
                Class<?> clazz = Class.forName(packageName + '.' + file.getName().substring(0, file.getName().length() - 6));
                // Does the file is annotated with the given annotation?
                if (clazz.getAnnotation(annotation) != null) {
                    classes.add(clazz);
                }
            }
        }
        return classes;
    }

NB: I used the example given in this post to write this code.

Thus, the code ClasspathClassesFinder.getSuiteClasses("my.company", FastTest.class) will return an array of classes that belong to the package my.company and annotated with @FastTest.

The next step consists in building a Suite that will use my utility class to find all the fast tests:

public class FastTestsSuite extends org.junit.runners.Suite {

    public FastTestsSuite(Class<?> clazz, RunnerBuilder builder) throws InitializationError {
        this(builder, clazz, ClasspathClassesFinder.getSuiteClasses("my.company", FastTest.class));
    }

    public FastTestsSuite(RunnerBuilder builder, Class<?> clazz, Class<?>[] suiteClasses) throws InitializationError {
        super(builder, clazz, suiteClasses);
    }

}

Last class to write: the entry point for the Maven Surefire plugin (this class will only run @FastTest, so I will have to write the same class for @SlowTest):

@RunWith(FastTestsSuite.class)
public class RunAllFastTests {

}

Now, I just need to configure Maven in order to run « only » this test:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <!-- Run only tests annotated with @FastTest. -->
        <includes>
            <include>**/RunAllFastTests.java</include>
        </includes>
        ...
    </configuration>
</plugin>

Please note that if you are working on a project with multi-modules (this is my case), you will have to define this RunAllFastTests.java in each module.

Regarding the slow tests, I just have to define a Maven profile that will launch the RunAllSlowTests class, which calls the Suite SlowTestsSuite. This Suite will use the utility class to find all classes annotated with @SlowTest. My continuous integration server Hudson Jenkins will activate this profile during the nightly-builds.

Conclusion

Finally, this solution is not really complex, and when the mechanism is developed, you just have to annotate your JUnit test class with the adequate annotation. This is simple.

However, I am quite disappointed that JUnit, a widely used test framework, does not provide such a mechanism natively. I hope that it will change in the near future…

Feel free to post your comments if you think that my solution is not the best one to solve this kind of problem.

Sources

Jean-Philippe Briend suggested me on Twitter to provide the sources of the classes. Here they are:

ZIP

This project requires Maven 2 or 3, Java 1.6 and JUnit 4.8.1.

In addition to all the classes required for the mechanism, this project contains three basic unit tests:

• OneFastTest, annotated with @FastTest ;
• OneSlowTest, annotated with @SlowTest ;
• TestWithoutAnnotation, without any annotation. As this test should not be executed, it contains a method that will call the JUnit fail() method. Thus, if this class is executed, the test will fail.

If you run the command mvn clean install, only the class annotated with @FastTest will be executed.
If you run the command mvn clean install -Djenkins=true (or -Pjenkins), both annotated classes will be executed.

Start Slide Show with PicLens Lite

Voici mon carnet de voyage…

Le contexte

Dans l’un de mes projets, je dispose d’une grande quantité de tests unitaires.
En réalité, parmi ceux-ci, beaucoup d’entre eux ne sont pas unitaires du tout. Ils nécessitent parfois un accès à la base Oracle, parfois un contexte Spring plutôt lourd à charger, etc. Bref, ce ne sont pas là de bons tests unitaires, lancés en isolation.

Le but est donc de pouvoir séparer les tests en diverses catégories.

Afin de simplifier les choses, je ne considèrerais que deux catégories ici : @FastTest et @SlowTest.

Solutions envisagées

JUnit a introduit dans la version 4.8 les @Category (voir le changelog et un exemple).
Le principe est d’annoter une classe (ou une méthode) avec @Category, et de définir à quelle catégorie ce(s) test(s) appartient(-nent). Pour notre besoin, nous pourrions donc écrire :

// Interfaces pour catégoriser les tests...
public interface FastTest { }
public interface SlowTest { }

@Category(SlowTest.class)
public class ASlowTest {
    @Test
    public void foo() { ... }
}

@Category(FastTest.class)
public class ARealUnitTest {
    @Test
    public void foo() { ... }
}

Bref, ça s’annonce plutôt bien. Mais si l’on regarde dans le détail, pour pouvoir lancer tous les tests d’une catégorie spécifique, il faut faire :

@RunWith(Categories.class)
@IncludeCategory(FastTest.class)
@SuiteClasses( { ARealUnitTest.class, AnotherRealUnitTest.class })
public class FastTestsSuite { }

Et c’est là notre souci : il faut créer une Suite (via l’annotation @SuiteClasses) afin de définir les classes devant être exécutées. Cela nous oblige donc à maintenir une liste exhaustive des tests à lancer pour une suite donnée. Les oublis risquent donc d’être fréquents…

Se passer des Suite JUnit

Comment pallier ce problème de Suite ? Rapidement, quelques idées me viennent :

• Ecrire des Suite manuellement comme on vient de le dire, mais avec le risque d’en oublier.
• Ecrire des Suite via un plugin Maven. J’en avais écrit un dans ce but il y a environ 2 ans et je pourrais m’en resservir. Mais la question est de savoir à quel moment il doit être lancé. Etant donné que mon plugin écrit ou modifie des classes de tests, on ne peut pas l’exécuter automatiquement ni n’importe quand. De plus, il se peut que certaines classes ne doivent pas être ajoutées dans ces suites, donc on ne peut pas considérer cette solution comme viable.
• Se baser sur des nommages spécifiques pour les classes de test. Par exemple tous les tests vraiment unitaires portent le nom de ***FastTest.java, les autres étant nommés ***SlowTest.java. Maven, et ses profiles, se chargeant ensuite de choisir quel pattern donné à Surefire. Bien qu’il s’agisse d’une idée intéressante, je ne suis que moyennement pour, car on risque d’avoir là aussi des oublis ou des erreurs.
• Utiliser TestNG, un autre framework de tests, proposant plus de fonctionnalités que JUnit. En particulier, TestNG permet de créer des groupes sur les tests, ce qui correspond à nos @Category de JUnit, mais qui marchent mieux. Le plugin Maven de tests – Surefire – gère nativement le support des groupes. C’est très simple, il suffit de définir une propriété dans la configuration Maven du plugin Surefire ! Mais dans mon cas, je souhaite rester sur du JUnit, bien que cette solution soit sans doute la plus élégante…
• Modifier le plugin surefire de Maven pour gérer les @Category de JUnit. Ne rigolez pas, j’ai essayé de le faire Mais modifier un plugin du coeur de Maven n’est forcément pas une bonne idée !

Sur ces cinq solutions, j’ai donc opté pour pour la sixième !

La sixième solution : Ne pas se passer des Suite !

L’idée consiste à utiliser des Suite de JUnit, mais que celles-ci soit générées dynamiquement.

Cette Suite va aller chercher dans le classpath les classes de tests annotées avec une annotation particulière.

Lors de mes recherches, je suis tombé sur le projet classpathSuite. L’un des intérêts de ce projet est de pouvoir construire une Suite en cherchant des classes présentes dans le ClassPath.

Ainsi il suffit d’écrire :

@RunWith(Categories.class)
@Categories.IncludeCategory(FastTest.class)
@Suite.SuiteClasses( { AllTests.class })
public class FastTestsSuite {
}

@RunWith(ClasspathSuite.class)
public class AllTests {
}

pour que classpathSuite cherche toutes les classes présentes dans le ClassPath appartenant à la catégorie FastTest.
Magique. Sauf que si ça marche très bien avec Eclipse, cela ne fonctionne pas lorsque les tests sont lancés par Maven.

Ou alors j’ai raté quelque chose !

Donc il faut refaire quelque chose de proche, mais qui marche avec Maven !

La solution

Première étape, je créé deux annotations simples : @FastTest et @SlowTest.
Ces annotations vont être utilisées pour annoter des classes de tests unitaires (dans cette solution, nous n’annoterons que les classes, et pas les méthodes). Grosso-modo ça remplacera les annotations @Category(FastTest.class) et @Category(SlowTest.class).

Ensuite, je crée une classe utilitaire qui va chercher dans tout le classpath les classes étant annotées par une annotation donnée (donc essentiellement @FastTest ou @SlowTest) et qui appartiennent à un package donné (ou un package fils).

Cela nous donne :

public final class ClasspathClassesFinder {

    /**
     * Get the list of classes of a given package name, and that are annotated by a given annotation.
     *
     * @param packageName The package name of the classes.
     * @param testAnnotation The annotation the class should be annotated with.
     * @return The List of classes that matches the requirements.
     */
    public static Class<?>[] getSuiteClasses(String packageName, Class<? extends Annotation> testAnnotation) {
        try {
            return getClasses(packageName, testAnnotation);
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }

    /**
     * Get the list of classes of a given package name, and that are annotated by a given annotation.
     *
     * @param packageName The package name of the classes.
     * @param annotation The annotation the class should be annotated with.
     * @return The List of classes that matches the requirements.
     * @throws ClassNotFoundException If something goes wrong...
     * @throws IOException If something goes wrong...
     */
    private static Class<?>[] getClasses(String packageName, Class<? extends Annotation> annotation) throws ClassNotFoundException, IOException {
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
        String path = packageName.replace('.', '/');
        // Get classpath
        Enumeration<URL> resources = classLoader.getResources(path);
        List<File> dirs = new ArrayList<File>();
        while (resources.hasMoreElements()) {
            URL resource = resources.nextElement();
            dirs.add(new File(resource.getFile()));
        }
        // For each classpath, get the classes.
        ArrayList<Class<?>> classes = new ArrayList<Class<?>>();
        for (File directory : dirs) {
            classes.addAll(findClasses(directory, packageName, annotation));
        }
        return classes.toArray(new Class[classes.size()]);
    }

    /**
     * Find classes, in a given directory (recurively), for a given package name, that are annotated by a given annotation.
     *
     * @param directory The directory where to look for.
     * @param packageName The package name of the classes.
     * @param annotation The annotation the class should be annotated with.
     * @return The List of classes that matches the requirements.
     * @throws ClassNotFoundException If something goes wrong...
     */
    private static List<Class<?>> findClasses(File directory, String packageName, Class<? extends Annotation> annotation)
            throws ClassNotFoundException {
        List<Class<?>> classes = new ArrayList<Class<?>>();
        if (!directory.exists()) {
            return classes;
        }
        File[] files = directory.listFiles();
        for (File file : files) {
            if (file.isDirectory()) {
                classes.addAll(findClasses(file, packageName + "." + file.getName(), annotation));
            } else if (file.getName().endsWith(".class")) {
                // We remove the .class at the end of the filename to get the class name...
                Class<?> clazz = Class.forName(packageName + '.' + file.getName().substring(0, file.getName().length() - 6));
                // Does the file is annotated with the given annotation?
                if (clazz.getAnnotation(annotation) != null) {
                    classes.add(clazz);
                }
            }
        }
        return classes;
    }

NB: Je me suis inspiré de ce post pour ce code, mais adapté à mes besoins.
Je n’ai pas regardé en détail, mais il est possible que le projet Reflections puisse faciliter l’écriture d’une telle classe, mais bon…

Ainsi, le code ClasspathClassesFinder.getSuiteClasses("my.company", FastTest.class) va me retourner un tableau de classes ayant comme package ancêtre my.company et annotées par @FastTest.

Je construit maintenant une Suite qui va utiliser cette précédente classe utilitaire pour me trouver les tests rapides :

public class FastTestsSuite extends org.junit.runners.Suite {

    public FastTestsSuite(Class<?> clazz, RunnerBuilder builder) throws InitializationError {
        this(builder, clazz, ClasspathClassesFinder.getSuiteClasses("my.company", FastTest.class));
    }

    public FastTestsSuite(RunnerBuilder builder, Class<?> clazz, Class<?>[] suiteClasses) throws InitializationError {
        super(builder, clazz, suiteClasses);
    }

}

Dernier élément, le point d’entrée de mes tests pour le plugin Maven Surefire :

@RunWith(FastTestsSuite.class)
public class RunAllFastTests {

}

Il ne me reste plus qu’à indiquer à Maven de ne prendre « que » ce test là :

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <!-- Run only tests annotated with @FastTest. -->
        <includes>
            <include>**/RunAllFastTests.java</include>
        </includes>
        ...
    </configuration>
</plugin>

Un petit bémol : si l’on travaille avec des projets multi-modules Maven (ce qui est mon cas), il faut que chaque module dispose de sa propre classe nommée RunAllFastTests.

Concernant les SlowTest, il me suffit de définir un profile Maven qui lancera la classe RunAllSlowTests, qui fera appel à la suite SlowTestsSuite qui appelle ma classe utilitaire pour trouver toutes les classes annotées par @SlowTest. Le serveur d’Intégration Continue Hudson Jenkins activant alors ce profile lors des nightly-builds.

Conclusion

Au final, il n’y a rien de bien méchant là-dedans, le principe une fois en place est simple (il suffit d’annoter la classe JUnit avec la bonne annotation). Mais je trouve cela regrettable que JUnit, pourtant très largement utilisé, soit aussi peu flexible pour un besoin somme toute très simple.

Donc si vous trouvez que j’ai sorti l’artillerie lourde pour rien, faites m’en part dans les commentaires, je suis curieux de voir comment vous vous y seriez pris !

Bonus

Suite à une suggestion de Jean-Philippe Briend, j’ai mis à disposition le code source d’un petit projet contenant toutes les classes évoquées ici.

ZIP

Le projet se builde avec Maven 2 ou 3, Java 1.6 et JUnit 4.8.1.

En plus de toutes les classes nécessaires au bon fonctionnement du mécanisme, il contient trois classes de test unitaires, pour montrer le principe en action :

• OneFastTest, annotée avec @FastTest ;
• OneSlowTest, annotée avec @SlowTest ;
• TestWithoutAnnotation, classe non annotée. Afin de montrer que ce test n’est pas exécuté, il contient une méthode qui appelle le fail de JUnit. Ainsi, si la classe est exécutée, le test échouera.

En lançant la commande mvn clean install, seule la classe annotée avec @FastTest est exécutée.
En lançant la commande mvn clean install -Djenkins=true (ou -Pjenkins), les deux classes annotées sont exécutées.

N’hésitez pas à me faire un retour sur ce projet si vous trouvez là aussi des énormités…

Start Slide Show with PicLens Lite

J’avais promis d’aller plus loin dans l’étude de ce framework, j’ai en fin de compte traduit l’intégralité du tutoriel présenté sur le site officiel. A travers ce tutoriel, vous pourrez découvrir plus de fonctionnalités de Play, d’apprendre la façon dont il gère la persistence, comment créer des pages complexes, d’ajouter de l’authentification, etc.

Vous pouvez lire ma prose sur mon site developpez.com !

Etape #1: Installons Play !

Pour installer Play!, rien de plus simple : il suffit de télécharger le ZIP (ici), puis de le décompresser sur son disque. C’est tout ! Pensons à ajouter le répertoire ainsi décompressé dans notre variable d’environnement Windows PATH, histoire de pouvoir taper la commande play en ligne de commande…

Etape #2 : Démarrons !

Allons à la racine de notre répertoire d’installation de Play!, et tapons la commande suivante :

d:\developpement\play-1.0> play new helloworld

La commande nous demande alors quelle est le nom de notre nouvelle application :

d:\developpement\play-1.0>play new helloworld
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0, http://www.playframework.org
~
~ The new application will be created in d:\developpement\play-1.0\helloworld
~ What is the application name? HelloWorld
~
~ OK, the application is created.
~ Start it with : play run heloworld
~ Have fun!
~

Notre première application est prête ! Eh oui ! Voyons les choses plus en détails… Regardons le contenu du répertoire ainsi créé :

app/
conf/
lib/
public/
test/

Ces répertoires ont les rôles les suivants :

• app : contient le code de l’application elle-même, à savoir les classes Java ainsi que les pages HTML.
• conf : les fichiers de configuration, en particulier application.conf qui contient les paramètres de notre application (par exemple le port du serveur, la configuration de la connection à la base de données, etc.), le fichier routes, qui définit les liens entre les URL et les pages web. Enfin, ce répertoire contient le fichier messages utilisé pour l’internationalisation du projet.
• lib : ce répertoire contient les librairies Java optionnelles.
• public : place contenant les ressources publiques, à savoir les images, les fichiers Javascript ou CSS.
• test : le répertoire permet de stocker les fichiers de tests, qu’il s’agisse de tests JUnit ou Selenium.

Et ça marche ? Voyons voir… Lançons la commande suivante :

d:\developpement\play-1.0\helloworld> play run

d:\developpement\play-1.0\helloworld>play run
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0, http://www.playframework.org
~
~ Ctrl+C to stop
~
Listening for transport dt_socket at address: 8000
20:15:17,611 INFO  ~ Starting d:\developpement\play-1.0\helloworld
20:15:20,579 WARN  ~ You're running Play! in DEV mode
20:15:22,111 INFO  ~ Listening for HTTP on port 9000 (Waiting a first request to start) ...

Rendons-nous sur l’adresse http://localhost:9000 (9000 étant le port par défaut du serveur Play !) pour visualiser la page par défaut :

Mais quelle est la magie ? Le fichier conf/routes définit le routage des requêtes au sein de notre application. En particulier :

# Home page
GET     /                                       Application.index

Cette ligne indique que lorsqu’un utilisateur se connecte à la racine de notre application (ici http://localhost:9000/), sa requête sera prise en charge la Application.index. Ce contrôleur est visible dans app/controlles/Application.java :

package controllers;

import play.mvc.*;

public class Application extends Controller {

  public static void index() {
    render();
  }

}

La première chose à constater ici c’est que notre contrôleur étend la classe play.mvc.Controller. Cette classe nous propose – entre autres – la méthode render() qui est ici utilisée dans l’action index. Cette action est par ailleurs définie comme une méthode publique et statique. C’est la façon de définir une action dans Play !. Dans cet exemple, cette dernière ne fait qu’afficher le contenu d’un template se trouvant dans app/views/Application/index.html (c’est le template utilisé par défaut, car nous n’en avons pas défini dans notre classe Java) :

#{extends 'main.html' /}
#{set title:'Home' /}

#{welcome /}

Ce template est divisé en trois parties. Tout d’abord, on y voit que notre template étend le main.html :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>#{get 'title' /}</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <link rel="stylesheet" type="text/css" media="screen" href="@{'/public/stylesheets/main.css'}" />
    <link rel="shortcut icon" type="image/png" href="@{'/public/images/favicon.png'}" />
  </head>
  <body>
    #{doLayout /}
  </body>
</html>

Dans ce fichier, on y voit le tag #{doLayout /} qui marque l’endroit où sera inseré le contenu du fichier Application/index.html.

Ensuite, on constate la façon dont un paramètre du template (le title) est passé à la page parente, via les #{set …/} et #{get …/}.

Enfin, la partie #{welcome /} génère le message d’accueil que nous avons pu voir précédemment.

Etape #3 :Utilisons Eclipse

Pour faciliter le développement de notre application, nous utilisons Eclipse. Pour ce faire, utilisons la commande suivante :

d:\developpement\play-1.0> play eclipsify helloworld

Play ! se charge alors de créer les fichiers nécessaires à Eclipse :

d:\developpement\play-1.0>play eclipsify helloworld
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0, http://www.playframework.org
~
~ OK, the application is ready for eclipse
~ Use File/Import/General/Existing project to import d:\developpement\play-1.0\helloworld into eclipse
~
~ Use eclipsify again when you want to update eclipse configuration files.
~ However, it's often better to delete and re-import the project into your workspace since eclipse keeps dirty caches...
~

Les fichiers nécessaires à l’importation du projet dans Eclipse sont désormais créés. Il s’agit du .project, .classpath et .settings/.

Voilà, nous avons notre première petite application Play ! qui tourne. On a vu deux ou trois concepts intéressants, mais il y a encore plein de jolies choses à découvrir sur ce framework (si vous avez suivi le lien du Touilleur que je vous ai donné en début de post, vous en avez déjà vu quelques unes) ! Nous les aborderons dans un prochain post, très bientôt !

Bonus

Voici la liste des options proposées par la commande play :

C:\developpement\play-1.0\>play help
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0, http://www.playframework.org
~
~ For all commands, if the application is not specified, the current directory is used
~ Use 'play help cmd' to get more help on a specific command
~
~ Available commands are:
~ ~~~~~~~~~~~~~~~~~~~~~~~
~ auto-test      Automatically run all application tests
~ classpath      Display the computed classpath
~ clean          Delete temporary files (including the bytecode cache)
~ eclipsify      Create all eclipse configuration files
~ help           Display help on a specific command
~ id             Define the framework ID
~ modules        Display the computed modules list
~ netbeansify    Create all netbeans configuration files
~ new            Create a new application
~ out            Follow logs/system.out file
~ pid            Show the pid of a running application
~ precompile     Precompile all Java sources and templates to speed up application start
~ run            Run the application in the current shell
~ restart        Restart the running application
~ secret         Generate a new secret key
~ status         Display the status of the running application
~ start          Start the application in background
~ stop           Stop the running application
~ test           Run the application in test mode in the current shell
~ war            Export the application as a standalone WAR archive
~
~ Also refer to documentation at http://www.playframework.org/documentation
~

Start Slide Show with PicLens Lite