• 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

David nous sort son premier joker, sous le nom de « git bisect« . Il faut savoir que Git est en réalité est constitué d’une batterie d’outils (un peu comme Maven avec sa pléthore de plugins, à l’exception que Git ne télécharge jamais tout Internet pour travailler ). « bisect » est l’un d’entre eux. Donc David sait que sur une version un peu ancienne, tagguée VERSION1.1.3, la commande Maven fonctionnait bien, mais plus maintenant. Il va donc demander à Git de trouver quand, dans cet intervalle de temps séparant la version 1.1.3 à aujourd’hui, la regression est apparue. Il lance donc la commande suivante :

git bisect start HEAD VERSION1.1.3

git bisect run sh -c « mvn eclipse:eclipse > /dev/null »

cat ../maveneclipse.sh

#!/bin/sh

mvn eclipse:eclipse > /dev/null

git bisect start HEAD VERSION1.1.3

git run ../maveneclipse.sh

running ../maveneclipse.sh

Bisecting: 140 revisions left to test after this (roughly 7 steps)

[49be0b426f3469b154d66179ecdbaad2128b872e] Now formats Javadocs

running ../maveneclipse.sh

Bisecting: 70 revisions left to test after this (roughly 6 steps)

[18a0eddab7a745c9cec538b9184efb25499e06c1] More optimisations

running ../maveneclipse.sh

Bisecting: 37 revisions left to test after this (roughly 5 steps)

[051bccc6252b23be6c9074545986cd057bcc69d8] Merge branch ‘master’

running ../maveneclipse.sh

Bisecting: 15 revisions left to test after this (roughly 4 steps)

[1183351cf1976571138c80dcf70e702dc3575177] Merge branch ‘master’

running ../maveneclipse.sh

Bisecting: 7 revisions left to test after this (roughly 3 steps)

[a586dcbddca57d93e00ed7ebaeb02239bfdc515c] Merge branch ‘master’

running ../maveneclipse.sh

Bisecting: 3 revisions left to test after this (roughly 2 steps)

[b4938d0a2aacabb4e71c2c08cab5e63ce12efbce] Merge branch ‘master’

running ../maveneclipse.sh

Bisecting: 1 revision left to test after this (roughly 1 step)

[6536952979f24786db146217b81f7d612bede425] Before we fix the build

running ../maveneclipse.sh

Bisecting: 0 revisions left to test after this (roughly 0 steps)

[56750bb15630dbf1af1976ad0e7161c7ed696e69] Force Maven3

running ../maveneclipse.sh

56750bb15630dbf1af1976ad0e7161c7ed696e69 is the first bad commit

commit 56750bb15630dbf1af1976ad0e7161c7ed696e69

Author: David Gageot <gageot>

Date:   Wed Mar 17 18:20:29 2010 +0100

Enforce Maven3

Voilà comment, en quelques secondes, l’outil Git bisect a permis à David de comprendre où était le problème, et comment du coup le résoudre (non, il n’existe pas encore d’outil corrigeant automatiquement les bugs dans Git ).

Mais dans les grandes lignes, David a bien insisté sur la simplicité de l’outil – bien qu’il soit assez déroutant aux premiers abords – mais également sur sa puissance et sa robustesse. Il nous a indiqué n’avoir jamais eu a pesté contre l’outil en 2 ans d’utilisation ! Connaissant David, je peux vous assurer que si un outil ne lui plaît pas, il ne se gênera pas pour qu’on le sache L’une des grandes forces de Git, c’est son intelligence à comprendre les structures des projets, de s’adapter facilement et de façon non intrusive aux différentes modifications du code, et à gérer d’une manière presque magique tous les merges.

Start Slide Show with PicLens Lite

Maven a une actualité assez chargée ces derniers temps, avec la sortie toute proche de la troisième génération de l’outil, mais également avec la publication d’un ouvrage sur Apache Maven, écrit par Nicolas de Loof et Arnaud Héritier.

J’ai écrit courant décembre deux articles sur le site developpez.com concernant ces actualités :

• Les nouveautés d’Apache Maven 3
• Critique du livre « Apache Maven » (résumé, version longue).

Bonne lecture, et n’hésitez pas à réagir à ces articles sur le site de developpez.com ou en commentaires ici !

Start Slide Show with PicLens Lite