Ma nouvelle version du blog est donc hébergée par GitHub Pages, propulsé par Octopress !
Ca se passe ici -> http://linsolas.github.com/
]]>Le but de cette présentation est de montrer les atouts de la librairie de tests Java TestNG, en particulier face à l’omniprésent JUnit.
Il faut l’avouer, aujourd’hui JUnit a réussi à combler certaines de ses lacunes par rapport à TestNG. Je pense par exemple au groupage / catégorisation des tests (JUnit 4.8 a introduit un
@Category bancal, mais grandement aidé par Maven Surefire depuis sa version 2.11), aux tests paramétrés (annotation @Parameters de JUnit), etc.Toutefois, je reste convaincu de l’intérêt de TestNG sur JUnit. Mais j’aimerais connaitre ton opinion…
Bref, toi, lectrice, lecteur de mon blog, si tu fais partie d’une catégorie suivante :
- 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
]]>
C'est'y pas collector ?
Devoxx, je connaissais déjà depuis à peu près 3 ans, mais de façon indirecte. Hélas, je n’avais jamais eu la chance de me rendre à Anvers pour assister à LA conférence des développeurs Java. Quand la conférence Devoxx France a été annoncée lors du Devoxx World en fin 2011, je me suis dit que je devais y être. Il ne pourrait pas en être autrement !
Pour m’y rendre, j’avais donc 4 possibilités :
- Devenir conférencier, en proposant un (ou plusieurs) sujet(s) ;
- Obtenir une place via le site Developpez.com, pour lequel je suis rédacteur et modérateur ;
- Me faire payer ma place par ma société, si possible par le biais du DIF (Droit Individuel à la Formation) ;
- M’offrir ma place, et poser 3 jours de congés pour m’y rendre.
L’aventure commence…
L’avant CFP
Début janvier, je commence donc le forcing auprès de ma hierarchie, pour privilégier la solution #3. Visiblement, ça a l’air plutôt compliqué, mais pas impossible.
Les semaines passent, et nous voici quasiment à la mi-février, date limite pour la soumission des conférences (CFP, ou Call For Papers). Là, je me dis que je m’en voudrais de ne pas avoir tenté ma chance, je décide donc de me lancer. Bien entendu, j’avais déjà réfléchit depuis plusieurs semaines à des sujets que je pourrais présenter. J’avais plus ou moins exclu mon domaine de prédilection, à savoir ce qui touche à l’usine logicielle (intégration continue, qualité logicielle avec Sonar, etc.) car je savais bien que d’autres personnes mieux placées que moi auraient plus de chances d’être sélectionnées. De plus, que dire de vraiment intéressant sur le sujet, sachant que l’audience d’un Devoxx est une audience de qualité, avec des gens très compétants qui connaissent très bien leur affaire ?
Bref, j’opte pour un sujet qui, à mon avis, peut avoir son attrait : l’industrialisation des tests JavaScript. J’avoue que je ne suis un grand expert dans le domaine, mais j’ai suffisament de connaissances pour en parler. Le temps presse avant la fin du CFP, il faut donc soumettre l’abstract rapidement, même si le contenu n’est pas encore tout à fait clair. Connaissant l’esprit et le ton décalés de Devoxx, je choisis un titre un peu fun : Chouchoutez votre code JavaScript. J’envoie donc ma proposition dans la catégorie Tools In Action. Cette catégorie est parfaite pour moi : une durée de 30 minutes, ce qui n’est ni trop court ni trop long, et un angle démo très prononcé. De plus, l’entrée à la conférence est offerte pour les speakers des Tools In Action, ce qui ne gâche rien.
Pour le fun, je soumets une deuxième proposition, cette fois-ci sous forme de Quickie (présentation rapide de 15 minutes) : TestNG, parce que vos tests le valent bien. J’ai soumis ce Quickie pour 2 raisons essentiellement :
- Parler de TestNG, un outil trop méconnu, loin derrière le fameux JUnit, et qui ne manque pourtant pas de qualités ;
- Avoir une chance de plus d’être conférencier, au cas-où mon Tools In Action soit refusé.
Voilà, les soumissons sont closes, l’équipe de Devoxx, en charge de faire le tri parmi tous les sujets, fait déjà une première constatation : c’est un carton plein ! Pas moins de 464 soumissions ont été faites ! Waouh, c’est impressionnant. C’est aussi beaucoup de stress, car on se dit que cela réduit les chances d’être choisi…
En attendant Devoxx France
Devoxx, ça arrive à grands pas !
L’équipe de Devoxx travaille vite, et le 16 février au matin, je reçois un mail : Your DevoxxFrance 2012 presentation was approved, qui commence par ces quelques mots : We’re excited to inform you that your « Chouchoutez votre code JavaScript » Tools in Action presentation has been accepted for DevoxxFrance 2012. Ce mail a tout simplement illuminé ma journée, ma semaine. C’était inespéré, me voilà donc conférencier pour Devoxx !
Ma session Quickie sur TestNG sera également retenue, d’abord en backup, puis officiellement. Je n’imaginais pas être voir l’une de mes soumissions acceptées, mais alors les deux ! Quelle joie… mais aussi quel défi. Je me rends finalement compte que ma chance a été de taper dans les catégories moins plébiscitée par les autres personnes. En effet, du côté des conférences (de 55 minutes), il me semble que seuls 17% des soumissions ont été acceptées !
Bon, ce n’est pas tout ça, mais il faut maintenant définir concrètement le contenu de mes deux présentations. Du côté de TestNG, je sais plus ou moins de quoi je parlerais, et comme ce sera avant tout des slides, je mets leur préparation de côté.
Pour Chouchoutez votre code JavaScript, j’ai déjà une ligne directrice assez claire, mais les détails restent flous : je commencerais à travailler avec Jasmine, un framework de tests (orienté BDD) pour du code JavaScript. Puis, je passerais sur une analyse avec l’outil Sonar, et je finirais par incorporer le tout dans un serveur d’intégration continue (Jenkins dans mon cas). Mes multiples essais sur ma machine donnent de bons résultats, mais il y a hélas un manque : avec tout ceci, je n’obtiens pas la couverture du code par les tests, chose aisée lorsque l’on travaille avec du code Java.
Et puis début mars, c’est la délivrance ! Sur la mailing list de Sonar, je vois un message annonçant l’arrivée de la version 0.4 du plugin JavaScript pour Sonar, avec en particulier le support de la couverture de code par js-test-driver. Je m’intéresse donc à cette librairie, et découvre avec joie que Jasmine propose un adaptateur pour js-test-driver.
Il ne me faudra pas beaucoup de temps pour faire marcher le tout ensemble, et obtenir ce que je voulais. Je suis sauvé !
Je m’occupe dès lors de mon Quickie sur TestNG. Les choses sont plus faciles, mais je m’aperçois que j’ai quelques années de retard En effet, TestNG est une excellente librairie de tests pour Java, qui offre depuis 2004 des fonctionnalités avancées que JUnit ne propose pas, ou alors seulement depuis 1 an ou 2. Je pense aux tests groupes de tests, à la dépendance entre tests, aux listeners, aux tests paramétrés, etc. Mais bon, je vais faire avec, et montrer que même avec les avancées de JUnit, TestNG reste une alternative qui a tout son sens, et qui dispose toujours de beaucoup d’atouts !
L’équipe de Devoxx fournit les templates pour Open Office, Microsoft Office et Apple Keynote. Etant sur Mac, j’avais tout d’abord opté pour Open Office. Après moults échecs dans mes tentatives de faire des slides à peu près jolis, je me suis dit que j’allais les faire sur un PC avec Office, et que je les jouerais avec Open Office sur mon Mac. Pas une très grande idée. Puis, j’ai décidé d’installer la version d’évaluation d’Office pour Mac, et je dois dire que je suis très rapidement tombé sous le charme.
Les choses vont donc bon train, mais rien ne vaut une vraie répétition. J’organise donc une répétition sur mon lieu de travail pour une poignée de collègues, une semaine avant le début de Devoxx France. Compte tenu que je vais emporter mon Mac perso, je n’aurais donc aucun réseau. La veille de cette répétition, je décide donc de la jouer chez moi, tout seul, mais en coupant mon wifi ! Grand bien m’en a pris ! Maven ne semble pas avoir apprécié sa déconnexion, et c’est une riche idée que j’ai eue de le tester en mode déconnecté.
Une chose à ce propos m’a un peu interpellé : ma démonstration sur le code JavaScript commence par la création d’un squelette de projet via un archetype JavaScript (de.akquinet.javascript.archetypes:javascript-quickstart pour être précis). Or, en mode déconnecté, la commande mvn archetype:generate ne me liste qu’une cinquantaine de choix (contre 578 une fois le wifi réactivé). Il m’a été impossible de trouver une option pour que Maven (ou le plugin Archetype) télécharge de lui-même le catalogue des archetypes sur le repository officiel de Maven. J’ai dû copié le archetype-catalog.xml manuellement pour qu’il reconnaisse bien l’ensemble des archetypes, même en mode déconnecté. Si vous avez une idée du pourquoi, n’hésitez pas à m’en faire part !!
Bon, à quelques petits détails près, ma répétition est appréciée, et en plus, j’ai réussi à tenir mes timings. Ca s’annonce plutôt pas mal…
Dernier petit stress : le week-end précédant Devoxx, Nicolas Martignole de l’équipe d’organisation, demande aux speakers de bien respecter le format « officiel » des slides, à savoir 1280×720, en particulier pour les conférences filmées (à savoir toutes, sauf les Quickies). Et dire que j’avais tout préparé en 1024×768 (la faute à mon Mac qui ne permet pas l’affichage en 16:9). Donc par souci de respect du protocole, me voici à copier ma présentation du format 1024×768 vers 1280×720. J’étais assez content que ma présentation soit surtout basée sur de la démonstration, et que du coup je n’avais qu’assez peu de slides (19 quand même).
Les jours J !
Mon Tools In Action sur JavaScript a lieu le premier jour de Devoxx France, à savoir le mercredi 18 avril. Je passe en fin d’après-midi, à 17h40. Tout pourrait aller à merveille, s’il n’y avait pas un petit souci d’ordre médical : je souffrais alors d’une angine ! 39,5 la veile au soir, j’avoue que je n’étais pas en grande forme. C’est donc à grand renfort de paracétamol (un traitement plus adapté suivra le lendemain, après avoir vu ma guérisseuse) que j’assiste aux premières conférences. L’après-midi, je le passerais à peaufiner ma présentation (c’est d’ailleurs 30 minutes avant ma présentation que j’ai rajouté les petits Godzilla en bas de mes slides, pour indiquer l’avancée dans ma présentation), à discuter avec d’autres personnes, et à assister à Code Story.
Puis, vint mon tour. Chose assez étrange : je n’ai pas (ou si peu) stressé avant, pensant que je stresserais comme un fou le jour J. Finalement, rien de tout cela, j’étais juste excité – dans le bon sens du terme – d’entrer sur scène ! Et pourtant, la salle, d’une capacité de plus de 200 personnes, était quasiment pleine !
Oui, il y avait du monde !
La preuve que c'était bien moi !
Je commence ma présentation, et à peine 3 minutes après le début de celle-ci, je m’ »offre » un bel effet démo ! Après avoir créer mon projet via l’archetype Maven, je m’en vais l’importer dans Eclipse… et là, c’est le drame ! Je commence par me tromper dans le chemin exact contenant mon projet, puis je me trompe dans la fenêtre de création de projets… bref, je commençais à paniquer (intérieurement seulement). Fort heureusement, le problème finit très vite par se régler, et le reste de la démonstration se passe à merveille ! Chose inattendue : au moment où j’obtiens la couverture de mon code JavaScript par mes tests sur Sonar, l’audience applaudit Ca fait chaud au coeur tout ça ! Je termine ma présentation dans les temps, j’ai même 4 minutes de questions, assez nombreuses d’ailleurs.
Visiblement, les retours sont bons, sur Twitter !
Le soir, un diner réservé aux speakers est prévu, je comptais y aller, mais j’ai préféré renoncé, compte tenu de mon état de santé. Ce mercredi, j’ai quitté Devoxx seulement quelques minutes après ma présentation, avec une énorme satisfaction. Pour moi, la mission était accomplie !
Le jeudi sera plus calme pour moi, car c’est la seule journée où je ne présente rien.
Le vendredi, mon Quickie passe à 12:35. La salle était, cette fois-ci, presque vide. Mais c’était à prévoir, les Quickies (surtout les premiers) étant planifiés en plein durant la pause déjeuner. J’ai fait ma présentation de TestNG sans grand souci, hormis que j’ai mis exactement 15 minutes pour la faire, alors que je voulais me réserver 2 / 3 minutes pour faire quelques démonstrations sous Eclipse. Tant pis, mais ce n’est pas grave…
Vivement Devoxx World et Devoxx France 2013
Finalement, Devoxx fut une conférence de très grande qualité, et faire partie des conférenciers fût pour moi une merveilleuse aventure !
Je remercie chaleureusement l’équipe de sélection de Devoxx pour m’avoir fait confiance, et avoir sélectionné mes deux présentations. Être conférencier Devoxx, c’est une énorme fierté en ce qui me concerne, et j’espère que ce sera partie remise l’année prochaine. J’espère d’ailleurs pouvoir proposer une vraie conférence (d’une heure), et pourquoi pas avec une autre personne… Mais d’ici-là, beaucoup de choses se seront passées !
Mille mercis aussi à Claude Falguière pour ses photos de Devoxx, ce qui me permet d’avoir un sacré souvenir de ma présentation (en attendant la vidéo sur Parleys ) !
]]>Je vais très rapidement zapper la toute première keynote, d’IBM. C’est un concentré, en une petite demi-heure, de ce qu’il ne faut pas faire dans une conférence, surtout à Devoxx : commerciale, speaker plutôt mou, et à l’opposé des présentations zen (c’est-à-dire avec des slides bourrées de bullets points).
Il suffisait de lire les tweets postés pendant la présentation pour comprendre que ce n’était pas du goût de l’auditoire !
Portrait du développeur en « The Artist » par Patrick Chanezon
Le conférencier suivant a un CV déjà bien rempli : il a travaillé chez Accenture, Netscape en France, puis Sun, Google (API / GAE), et enfin VMWare (CloudFoundry) aux USA.
La première partie est consacrée à nous parler de la vie de George, à la façon « The Artist« .
George est un développeur talentueux, et très vite devient indispensable à son projet. Ses chefs se disent qu’il serait bien de le mettre comme chef de projet, puis finalement comme DSI de sa boite… Mais voilà, George aime la technique, et si son niveau de golf s’améliore, il n’arrive déjà plus à lancer Eclipse, et est très vite dépassé par toutes les nouvelles technologies.
Patrick nous explique finalement que si l’on souhaite conserver son niveau, il faudra rester proche de la technique, et toujours s’intéresser aux nouvelles technologies…
Abstraction Distractions for France par Neal Ford
Nous continuons avec une troisième keynote, elle aussi de très haut vol. Il faut dire que nous avons en face de nous Neal Ford, un architecte de ThoughtWorks, et plutôt talentueux conférencier.
Cette fois-ci, il nous parle d’abstraction et de distraction. Difficile de retranscrire ici sa prestation, je vous la recommande sur Parleys dès qu’elle sera disponible. La moitié de la salle a fini debout pour applaudir le Maitre !
TestNG, parce que vos tests le valent bien par moi-même
Je reviendrais un peu plus longuement dans un autre billet sur le Quickie que j’ai présenté.
Il s’agit ici de montrer que TestNG dispose de nombreux atouts pour remplacer JUnit comme librairie de tests unitaires…
CRaSH par Julien Viet
Julien Viet, de l’équipe d’eXo plateform, nous propose une petite démonstration de CRaSH, un shell qui permet de travailler directement avec / sur une JVM.
Le principe est très simple : une fois installé et démarré, l’outil va se connecter sur une JVM, et on pourra alors exécuter un certain nombre de commandes :
- Lister les threads qui tournent sur la JVM ;
- Utiliser CRaSH pour gérer les logs, en changeant par exemple dynamiquement le niveau des logs du serveur d’applications JBoss AS ;
- Se connecter à la dataSource pour exécuter des requêtes SQL !
Puis Julien nous explique que les commandes sont écrites en Groovy et toute modification d’une commande est prise en compte dynamiquement. Il est d’ailleurs très simple d’ajouter soit-même de nouvelles commandes.
Bref, un bel outil, très extensible, qui mérite un coup d’oeil, même s’il ne faudra pas mettre cela entre toutes les mains !
Groovy 2.0 : quoi de neuf doc ?, par Guillaume Laforge et Cédric Champeau
Guillaume et Cédric nous font un récapitulatif des nouveautés de Groovy 2.0 (mais aussi un peu de Groovy 1.8).
En effet, déjà pas mal de choses ont été introduites par la version 1.8 du langage. Par exemple, les Command chains, rendant optionnelle l’écriture des . ou ( ), lorsque l’on chaine des appels.
Ainsi, ces codes :
turn left then right
check that: margarita tastes good // named-args
given {} when {} then {}
select all unique() from name // Pour une méthode sans argument, on garde les ()
take 3 cookies
sont équivalents à ceux-ci :
turn(left).then(right)
check(that: margarita).tastes(good) // named-args
given({})when({})then({})
select(all).unique().from(name)
take(3).cookies
Groovy intègre également GPars pour faire du parallélisme, de la concurrence.
Autre nouveauté : les Closure annotation parameters, ainsi que la memoization, c’est-à-dire que Groovy va se souvenir du dernier appel d’une closure pour cacher le résultat. Par exemple :
def plus = { a, b -> sleep 1000; a + b}.memoize() // on "simule" un traitement lent avec le sleep...
assert plus(1, 2) == 3 // Le retour sera fait après 1000ms
assert plus(1, 2) == 3 // Ici, on utilise le cache, donc le retour est immédiat
assert plus(2, 2) == 4 // Le retour sera fait après 1000ms, les paramètres étant différents.
assert plus(2, 2) == 4 // Ici, retour immédiat
On peut affiner la façon dont Groovy va cacher les résultats, en limitant par exemple le nombre de valeurs à retenir (.memoizeAtLeast(x), .memoizeAtMost(42)…).
Groovy ajoute désormais un support du JSON dans Groovy (avec les JsonSlurper, JsonBuilder et JsonOutput).
De nouvelle annotation (AST transformations) sont également à l’ordre du jour, comme par exemple @Log pour injecter automatiquement un logger.
Des annotations pour le controle d’exécution sont là : @ThreadInterrupt, @TimedInterrupt.
Les amateurs de Lombok seront aussi comblés, puisque Groovy intègre des annotations pour simplifier le code : @ToString (qui génère la méthode toString() automatiquement), @TupleConstructor (qui génère un constructeur avec les propriétés de la classe) ou encore @InheritConstructors (utile sur les exceptions où les constructeurs appelent juste des super).
Concernant Groovy 2.0, nous allons voir surtout la vérification stricte, ainsi que la compilation statique.
A noter aussi que cette version offre plus de modularité : ce n’est plus seulement un gros jar, mais plusieurs modules.
Groovy 2.0 s’adapte aussi à Java 7 :
- project coin (écriture des nombres en binaire, avec des _)
- multicatchs ;
- opérateur diamand (pour écrire
Listplutôt quelist = new ArrayList<>(); List) ;list = new ArrayList (); - invokeDynamic.
Le @TypeChecked fait aussi son apparition. Cette annotation permet de vérifier beaucoup plus de chose lors de la compilation.
Par exemple :
@TypeChecked test() { // On annote la classe ou la méthode
metthhoood() // Erreur à la compilation
def name = "Guillaume"
println // Erreur ici aussi !
}
Un autre exemple :
@TypeChecked test() {
["a", "b", "c"].collect(
it.toUpperCase()
)
}
ne compilera pas, car rien ne permettra d’assurer à Groovy que le it est bien un String (la méthode collect pourrait être alterée par exemple).
Du coup, pour que le compilateur soit content, il faut caster le it comme ceci :
@TypeChecked test() {
["a", "b", "c"].collect(
String it ->
it.toUpperCase()
)
}
Dernier point apporté par Groovy 2.0, et non des moindres : la compilation statique. Celle-ci se dénote par l’annotation @CompileStatic.
Les avantages d’une compilation statique sont :
- Les performances accrues, en particulier sur des JDK avant 7, ne disposant pas du
invokeDynamic; - Evite les problèmes liés au « Monkey patching« , c’est-à-dire que le code est « immunisé » contre la modification dynamique ;
- Le bytecode généré sera bien plus petit.
Reste que la compilation statique fait perdre les fonctionnalités dynamiques de Groovy (du moins sur le code compilé statiquement). Mais là, rien de bien gênant…
Android, graphisme et performances par Romain Guy
Romain Guy est un développeur français parti chez Sun où il a d’abord travaillé sur Swing, et est désormais chez Google comme développeur Android.
Il nous donne sur cette conférence un aperçu des écueuils à éviter lorsque l’on développe sur Android, et en particulier de ce qu’il convient de faire pour avoir des applications performantes.
Bon, je dois l’admettre, je n’ai pas retenu grand chose de la présentation car je ne développe pas pour Android. Toutefois, on voit que Romain connait son sujet, et qu’il maitrise l’art de la conférence. Bref, c’était agréable à écouter…
Les CastCodeurs en direct de Devoxx France
Très bonne conclusion du Devoxx avec cet enregistrement en live des CastCodeurs.
Un récapitulatif dans la joie, la bonne humeur et la bière (merci Atlassian pour ça !)
Vous pouvez retrouver l’épisode spécial Devoxx France ici.
Conclusion
Devoxx France, c’est fini, mais qu’est-ce que c’était bien !
Des conférences de haut niveau, un public de geeks très nombreux et aussi de grande qualité, des rencontres vraiment sympas.
Le fait d’avoir aussi été choisi comme conférencier pour parler de JavaScript (dans une présentation qui a visiblement plû au delà de mes espérances), et de TestNG rend ces jours vraiment inoubliables…
Bref, encore mille bravos à toute l’équipe organisatrice !
]]>Une petite visite chez le médecin en cette matinée m’a fait raté les keynotes. Je les regarderais sur Parleys lorsqu’elles seront disponibles.
Mais en gros, on salue le succès de cette première édition, et l’année 2013 verra elle aussi son édition parisienne du Devoxx ! J’ai déjà hâte d’y être !
Spring est mort, longue vie à Spring, par Gildas Cuisinier
Lorsque JavaEE 6 est sorti, on annonçait une guerre sans pitié avec Spring, et la fin proche de ce dernier.
Cela fait déjà 2 ans que JavaEE est sorti, mais qu’en est-il aujourd’hui ?
A l’époque, avant sa version 6, JavaEE avait « menti », en partiulier sur la soit disant simplicité du framework JavaEE, ainsi que sur la testabilité des applications l’utilisant…
C’est alors que Spring est arrivé pour résoudre pas mal de problèmes.
Initialement, toute la configuration se faisant avec des fichiers XML. Il faut dire que c’était à la mode, le XML !
Puis, la complexité de cette configuration augmentant, les namespaces sont arrivés, pour mieux catégoriser sa configuration Spring. On y voyait déjà plus clair !
Un jour, Java 5 est arrivé, en introduisant les annotations dans le code Java. Ceci va impliquer une nouvelle évolution de Spring : la configuration via les annotations.
En voici un exemple :
@Component
public class Jedi {
private Arme arme;
@Autowired
public void setArme(Arme arme) {
this.arme = arme;
}
}
Seul ombre au tableau : pour se passer d’écrire de la configuration en XML, il faut écrire… du XML. En effet, il faut indiquer à Spring quel(s) package(s) doivent être scannés pour y lire les annotations :
<context:component-scan base-package="xxx"/>
Entre temps, JavaEE est arrivé, et devient « sexy » : simplicité, testabilité, légèreté. Toutefois, cela demande une migration, non seulement du code, mais aussi des serveurs d’applications, car tous ne sont pas compatibles JavaEE 6.
De son côté, Spring sort en version 3.0 (décembre 2009), disposant de sa configuration par annotations.
Malgré l’arrivée de JavaEE 6, les équipes ne souhaitent pas abandonner Spring. Gildas nous le montre avec un certain nombre de statistiques tirées de son questionnaire Spring (entre 100 et 130 personnes y ont répondu).
Aujourd’hui, Spring est toujours très présent, en particulier les version 3.x :
- 50% des sondés utilisent Spring 3.0 ;
- 23% sont déjà passés à Spring 3.1 ;
- 19% n’utilisent pas Spring ;
- 8% sont restés sur des versions 2.0 ou 2.5 de Spring.
- Trop compliqué à mettre en place. Généralement, on travaille sur une application où Spring est déjà en place, on ne regarde pas comment cela fonctionne concrètement.
- Invasif.
- Trop de XML. Maintenant, on s’oriente beaucoup plus vers les annotations, comme pour JavaEE. Cependant, cela pose un autre souci : la configuration par annotations étant dispersée dans le code, il devient plus fastidieux d’avoir une vision globale de celle-ci…
- L’aspect propriétaire. Toutefois, si SpringSource gère seul le code, mais reste ouvert aux propositions.
D’ailleurs, dans l’audience, seules 3 personnes utilisent JavaEE 6 en production, alors que la quasi totalité utilise Spring 2.5 / 3.0 en production. Très peu (pour l’heure), utilisent Spring 3.1 en production.
Les principaux reproches faits à Spring :
Gildas parle ensuite de Spring 3.1. Qu’apporte-t-il ?
Spring 3.1 finit ce que Spring 3.0 avait introduit : tout est désormais annotable, on peut faire du « NoXML » !
L’exemple cité plus haut s’écrira désormais ainsi :
@Configuration
@ComponentScan("xxx")
public class Configuration {
...
}
De nouvelles annotations arrivent, pour gérer le scheduling (@EnableScheduling) ou encore pour configurer Spring MVC (@EnableWebMvc).
Les annotations ne permettent pas tout, et il est parfois nécessaire, en plus d’annoter sa classe, d’étendre une classe de Spring (exemple : les Interceptors MVC).
D’autres points intéressants sur Spring 3.1 :
- Support d’Hibernate 4 ;
- Namespace
c:(pour simplifier les constructeurs) ; - JPA sans le
persistence.xml; - Amélioration du support REST dans Spring MVC ;
- FlashMap dans Spring MVC.
En conclusion, Spring est loin d’être mort, car l’adoption de JavaEE est encore loin d’être une réalité, et de plus, Spring dispose de tout un écosystème autour de lui : SpringData, SpringMobile, SpringSocial, SpringBatch, etc.
Après la pause déjeuner, je vais zapper les conférences, et aller voir un peu ce qui se fait du côté de Code Story…
Code Story
Le principe : 4 développeurs (David Gageot, Jean-Laurent de Morlhon, Sébastien et Eric le Merdy) se chargent du développement d’une application se connectant à Github pour créer un historique de projet.
Ensuite, cette application va s’interfacer avec Jenkins, Sonar, Trello, etc. pour pouvoir ajouter des événements dans la vie du projet (build cassé, règle de qualité non respectée, etc.).
Au final, l’application devrait pouvoir attribuer des badges aux développeurs du projet surveillé : le meilleur casseur de build, le commiteur le plus prolifique, etc.
Tout se fait bien entendu en live, en partant de zéro.
Chaque itération dure environ 1 heure, avec 2 sessions de 25 minutes de développement.
Au début, un petit stand-up meeting pour expliquer ce qui va être fait dans l’itération, et à la fin, une rétrospective pour expliquer les accomplissements, ainsi que les difficultés rencontrées.
Concrètement, l’équipe se divise en 2 binômes :
- Le premier binôme est au front : il code face à l’audience, et explique à voix haute ce qu’il fait.
- Le second binôme travaille plus en retrait, et on ne voit pas concrètement ce sur quoi il travaille (mais on finit par le savoir lors de la rétrospective de fin d’itération).
Deux vidéo-projecteurs nous permettent de suivre leur travail en direct. Le premier diffuse l’écran du premier binôme (en général pour montrer soit IntelliJ, soit une console shell, soit le navigateur web), le second montre le « serveur », avec Jenkins ou Sonar qui analysent en permanence le travail commité sur GitHub.
Lorsque j’y suis allé, le projet n’en était encore qu’à ses débuts, et l’équipe mettait en place le déploiement automatisé, et commençait à écrire ses premières pages web.
Mais il était intéressant de voir 4 développeurs plutôt talentueux (dont 3 ex-collègues à moi ) travailler en direct live, dans des conditions proches de la réalité (avec des dead-lines très courtes).
D’ailleurs, à en voir les retours, ce Code Story a été très apprécié. Plusieurs fois j’ai voulu y retourner, mais à chaque fois, j’ai été obligé de rester en dehors de la salle, tant elle était perpétuellement remplie !
A noter que lorsque j’y suis passé, l’équipe avait déjà eu recours à pas mal d’outils ou de librairies :
- Github (version entreprise) pour stocker le code ;
- Infinitest pour laisser l’IDE exécuter en permance les tests unitaires ;
- Zombie.js un framework JavaScript pour tester l’interface web ;
- Mocha un autre framework de tests JavaScript ;
- Jersey, une librairie Java pour faire du REST ;
- Fest-assert, une extension à JUnit (ou TestNG) pour écrire des assertions de manière plus fluide (fluent) ;
- Guava l’incontournable librairie de Google pour ajouter tant de choses manquantes à Java !
- Growl un outil de notification pour Mac, affichant une notification à chaque fois que l’application vient à builder ;
- Jenkins pour l’intégration continue ;
- Sonar pour l’analyse qualité ;
- IntelliJ, l’IDE Java de référence ;
- Trello comme mur à post-its virtuel, permettant de planifier les tâches des itérations ;
- Mustache.js un framework JavaScript de templating.
L’équipe a mis en place le build incassable : on ne committe que si ça compile bien chez soi. Du coup, Jenkins devient moins utile. D’ailleurs, à ce propos, il faut noter que David Gageot est partisan de l’intégration continue sans serveur !
Grawl est également mis en place pour offrir un maximum de réactivité : dès qu’un commit est réalisé sur le repository Git, Grawl nous indique qu’un build Jenkins démarre… puis quelques secondes plus tard il nous indique que le build est terminé, avec succès bien sûr !
Une librairie qui a atiré mon attention, c’est Mustache.js, qui permet de faire du templating en JavaScript.
Voici un exemple tout simple :
<script type="x-template" id="commit-template">
{{#commit}}
<div class="commit">{{author}}</div>
{{/commit}}
</script>
Mustache.to_html($("commit-template").html, json);
Bref, une très jolie expérience que ce Code Story ! Dommage que je n’ai pu assister à des sessions vers la fin, pour voir le projet presque abouti.
Toujours est il que le code est à retrouver sur GitHub.
BigData et Hadoop par Pablio Lopez
Pablo Lopez nous parle d’une expérience vraiment très intéressante. Il travaille pour une grande société de vente de produits en ligne (il ne le citera pas, mais il s’agit d’une société à l’image ferroviaire vendant différentes prestations de voyages).
Celle-ci gère environ 1,000,000 de visiteurs uniques par jour, et environ 1/5 de ces visiteurs réalisent une commande.
Ce sont ainsi au total environ 65,000,000 commandes par an, avec un pic, autour de mi-octobre, de 350,000 ventes pour une seule journée !
L’ambition : être le leader mondial dans son activité dans les 3 ans. Rien que ça, pour, ce qui était il y a encore 10 ans à peine, une startup…
Côté technique, nous avons 500 serveurs de production, gérant environ 80 applications, chaque serveur disposant de 5 JVM. L’utilisateur navigue sur 13 niveaux de load balancing. Joli !
Au final, chaque serveur va générer 7 Go de logs quotidiennement ! Il est donc difficile de gérer un tel volume !
Ce qu’il faut, c’est :
- Centraliser les logs ;
- Sécuriser les fichiers de logs, les sauvegarder ;
- Analyser : pouvoir récupérer les informations selon des catégories (paiement, recherche, etc.) ;
- Informer les bonnes personnes avec les bonnes informations ;
- Archiver, pouvoir comparer les logs d’une journée sur l’autre, d’une semaine sur l’autre, d’un mois sur l’autre, etc.
- Et tout cela en temps réel s’il vous plait !
- MongoDB une base de données NoSQL ;
- Play pour afficher des statistiques, des rapports ;
- Hadoop
- Flume
- Elasticité du modèle, pour le faire évoluer facilement ;
- Facilement interrogeable, avec du JSON ;
- Maturité de l’API de requêtage ;
- Scalabilité.
- Analyse quotidienne des logs, pour le SLA (« Service Level Agreement« , autrement dit un document définissant le niveau de qualité attendu) ;
- Corrélation des logs. Si un utilisateur a eu un problème, il faut savoir identifier les serveurs par lesquels il est passé (on rappelle qu’un utilisateur peut passer par 13 niveaux de load-balancing !) ;
- Comparer différentes versions du site, voir si la nouvelle version ne contient pas des liens cassés par exemple.
- L’équipe soit avoir de nouveaux uses cases : par ex. savoir où passe le robot Google, détecter les utilisations frauduleuses de CB, faire des ratio recherches / achats ;
- Agrandir encore la plateforme, remettre à jour les machines ;
- Avoir de l’analyse de logs à la demande, sans avoir à développer et déployer de nouveaux map / reduce. Utiliser Hive ? Cascading ?
- Quel avenir pour les produits utilisés ? L’équipe souhaite contribuer à Flume. Quelques craintes également sur la versatilité d’Hadoop.
Etant un site de e-commerce, on doit avoir une disponibilité de 99,995%, ainsi qu’un temps de réponse sous la seconde (voire même sous les 200 ms). Et là dessus, il n’y a pas de négociation possible !
La base de données étant le « Single point of failure » (goulot d’étranglement), il ne faut surtout pas la surcharger !
Quelles solutions ?
Pour arriver à leurs fins, l’équipe de Pablo va avoir recours à :
Les outils doivent tenir la charge, être scalables, avoir une excellente tolérance à la panne.
Première chose : centraliser les logs, et le plus vite possible. Pour cela, ils font appel à SyslogAppender, un appender de log4j, qui peut transmettre les logs via UDP. De l’autre côté, syslog-ng est utilisé pour écouter ces packets UDP.
Flume est utilisé pour pouvoir copier les logs sur des systèmes de fichiers distribués (hdfs).
Second point : sécuriser les fichiers.
HDFS (Hadoop Distributed File System) est utilisé ici. Chaque log est copié 3 fois, sur des disques « classiques ». Cette duplication rend ainsi obsolète des système de type RAID.
hdfs travaille mal avec des « petits » fichiers (moins de 64Mo). Pour résoudre ce problème on regroupe plusieurs « petits » fichiers un seul (fichier de type .har).
Il faut maintenant analyser les logs, par « tranche » de 64M (sur le principe du principe map / reduce).
Les rapports d’analyse sont stockés sur du MongoDB :
Play! est utilisé pour représenter les rapports d’analyse. Play! est choisi pour sa facilité de mise en oeuvre, son intégration de JSON et MongoDB, etc.
Dernière problématique : le temps réel !
Premier souci : Hadoop ne sait pas faire de map / reduce sur des fichiers non fermés (or ici, tout est en streaming). Flume va résoudre ce problème en fermant les fichiers à chaque minute.
Hélas, le temps de traitement du map / reduce est alors d’environ 45 minutes ! Beaucoup trop long !
La première correction sera de modifier le cluster. Ensuite, les JVM gérées par Hadoop sont tunées, en particulier pour la gestion mémoire.
L’interaction avec Flume est également améliorée. On arrive maintenant à 6 minutes. C’est déjà mieux, mais le temps doit encore être réduit !
On optimise l’utilisation de Java : suppression de librairies tierces, optimisation de la sérialisation des objets, etc.
Au final, on arrive à 45 secondes pour traiter 1 minute de logs.
Quelle est l’utilisation quotidienne de ce système ?
Concernant l’avenir :
Dernier détail : l’investissement s’est fait essentiellement au niveau des machines (~ 70K€).
Le projet, quant à lui, est passé des premières discussions à la machine à café à la production en l’espace d’environ 7 à 8 mois.
Voilà un joli projet, qui montre une utilisation concrète d’Hadoop, MongoDB, Flume et Play! pour un traitement massif des logs.
Start Slide Show with PicLens Lite]]>Ca y est. Après plusieurs mois de préparation et d’attente, la conférence Devoxx a enfin lieu !
Parlons de lieu justement. Devoxx France prend place à l’hôtel Mariott, dans le 14e arrondissement de Paris.
Le lieu est donc plutôt bien choisi, et la conférence va s’étaler sur 2 niveaux :
- Au rez-de-chaussée, il y a 3 salles (Seine A, Seine B et Seine C), qui seront réunies en une seule lors des keynotes. C’est également à ce niveau-là que sont regroupés tous les stands des sponsors : Valtech, Xebia, Zenexity, Ippon, Google, etc. Enfin, c’est ici qu’ont lieu les buffets. Parce que ça creuse tout ça !
- Au niveau -1, 2 salles sont utilisées (Ella Fitzgerald et Miles Davis qui sera occasionnellement divisée en 3). Il y a aussi un open-space, très sympa pour les discussions un peu à l’écart, et une petite salle qui héberge 2 jours durant le Code Story.
Bref, au niveau des lieux, c’était un sans faute, même si au moment du buffet du midi, on se marchait un peu dessus…
On regrettera quelques petits soucis au niveau service, comme par exemple la manque de diversité au repas du midi (quelques salades, 2 ou 3 types de sandwiches, c’est tout), l’absence d’eau tout l’après-midi (c’est un peu abusé là je trouve), et des vestiaires qui ferment trop tôt (en particulier pour les gens qui ont des valises).
Ok, on chipote…
A part ça, au niveau de l’organisation, et du staff, pour moi, c’est zéro faute. Toujours présents, très réactifs en cas de soucis, aucune queue pour récupérer son badge. Bref, un seul mot : BRAVO.
Voyons maintenant un peu les sessions du jour… programme qui sera assez léger en ce qui me concerne.
Ce premier jour est destiné aux universités (des sessions techniques d’environ 3 heures), des démonstrations d’outils.
Tout le monde n’est pas encore là (certains participants ne vennant que les 2 deniers jours), mais nous sommes déjà autour de 800 personnes. Pas mal du tout !!
Les 5 mercenaires du DevOps, par Henri Gomez, Arnaud Héritier, Gildas Cuisinier, Pierre-Antoine Grégoire, Dimitri Baeli
Il existe aujourd’hui dans beaucoup de sociétés un véritable mur entre les équipes de développement et les opérationnels, c’est-à-dire les « gardiens » de la production.
Il arrive fréquemment que les livrables soient donnés aux opérationnels par les développeurs sans que ces derniers ne connaissent l’environnement de production.
De même, les « Ops » ne connaissent que trop peu ce qu’ils vont mettre en production.
Il en résulte généralement que lorsqu’un problème arrive en production, c’est à qui se débarrassera du problème, et surtout d’en nier la responsabilité (« Ton livrable est pourri« , « Mais tu n’as pas respecté l’étape 42 de la page 37 du document de mise en production« , etc.)!
Bref, nos 5 compères nous expliquent ce que sont les DevOps, mi-développeur mi-opérateur, et vont tenter de nous montrer ce que cela donne en live, grâce à une application qu’ils ont développé (une application de partage temporaire de fichiers).
Pour évaluer un peu leur audience, nos 5 mercenaires décident de faire les 12 tests de Joel : Joel Spolsky a édicté un test de 12 questions pour évaluer la qualité de l’environnement de travail d’un développeur.
Ces 12 questions, les voici :
- Disposez-vous d’un gestionnaire de source (type SVN, Git, etc.) ?
- Pouvez-vous construire vos livrables en une seule étape ?
- Construisez-vous l’application quotidiennement ?
- Avez-vous un gestionnaire de défauts ?
- Corrigez-vous les bugs de votre application avant d’écrire du nouveau code ?
- Avez-vous un planning à jour ? Autrement dit, avez-vous une visibilité d’au moins 15 jours dans votre travail ?
- Avez-vous des spécifications ?
- Les développeurs sont-ils dans un environnement de travail calme ?
- Disposez-vous des meilleurs outils, compte tenu de votre budget ?
- Avez-vous des testeurs (autres que des développeurs) ?
- Les candidats écivent-ils du code avant leur embauche ?
- Faites-vous des tests d’utilisabilité ?
Pour Joel, si vous avez une note inférieure à 10, alors vous avez un gros problème.
Notez que ce test, toujours d’actualité, a été écrit en 2000 ! Ce test a donc 12 ans, mais hélas beaucoup de développeurs ne peuvent encore jouir d’un score parfait.
D’ailleurs, nos 5 mercenaires demandent à l’audience de se lever, puis ils énumèrent ces règles, chaque participant devant se rassoir dès que l’une des règles n’est pas respectée dans son équipe. Au bout du test, seules 3 personnes finiront debout ! C’est peu.
L’équipe a ensuite montré l’application qu’ils ont développée, en montrant les différentes étapes pour pouvoir la déployer (via différents jobs Maven dirigés par un serveur Jenkins). La suite de la conférence – que je n’ai pas vraiment pu suivre – a consisté à modifier en direct l’applications, puis de la déployer « en production ».
Une première session plutôt agréable donc, présentée par quelques personnalités…
Hackergarten
Le principe du Hackergarten est assez simple : vous réunissez quelques geeks avec leur machine (généralement un Mac 
), ainsi qu’un commiteur (voire le créateur) d’une librairie ou d’un framework assez connu.
Ensuite, vous commencez à travailler sur le projet, en corrigeant un petit bug par exemple, ou en ajoutant une nouvelle fonctionnalité.
Ici, nous avions du choix : nous pouvions travailler sur Jenkins (ou un de ses nombreux plugins), Groovy, FluentLenium, Mockito, etc. Plusieurs personnes étaient là pour nous aider : Arnaud Héritier, Mathilde Lemée, Brice Dutheil, Guillaume Laforge, etc.
C’est une expérience sympathique, mais je n’y étais sans doute pas très bien préparé, en particulier le fait de devoir télécharger pas mal de sources (et je ne parle pas des dépendances Maven ).
Au final, je n’ai pas vraiment contribué à Jenkins, mais ce n’est sans doute que partie remise !
Chouchoutez votre code JavaScript par moi-même
Ma présentation, donc forcément une très bonne présentation, vous n’en doutez-pas
Plus sérieusement, cette présentation a un but précis : montrer que l’on peut faire pour le JavaScript ce que l’on fait déjà pour son Java, à savoir le tester, l’analyser, l’intégrer. Et le tout, sans utiliser de nouveaux outils.
Vous pouvez retrouver pour cette présentation :
- La retranscription sur mon blog
- Les slides sur SlideShare
- Les sources (mes backups) sur GitHub
- La vidéo sur Parleys (à venir)
Il restait encore une dernière série de présentations, un paquet de BOF (Birds of a Feather, c’est-à-dire un petit groupe de discussion informel sur un sujet précis) puis une soirée dédiée aux speakers, mais mon état de santé ne m’a hélas pas permis de rester.
Start Slide Show with PicLens Lite]]>Le but de cette présentation est de montrer qu’il est aussi facile de tester et analyser son code JavaScript que son code Java. Les mêmes outils seront d’ailleurs utilisés, en particulier Maven, Jenkins et Sonar.
Avant toute chose, nous allons prendre underscore.js comme cobaye pour nos tests. Pour information, il s’agit d’une librairie proposant une soixantaine de fonctions JS permettant de faire de la programmation fonctionnelle.
Etape #1: Créer le projet
Mon choix, pour la première librairie de tests, c’est Jasmine. Il s’agit d’une librairie avec une communauté assez active, et disposant d’un certain nombre de supports : Java et Maven, .Net, Ruby, Node.js, etc.
Pour être plus précis, cette librairie va être surtout utilisée lorsque l’on souhaite faire du BDD (Behavior Driven Development). D’ailleurs, dans la terminologie de Jasmine, on ne parle pas de test, mais de spec.
Comme dit précédemment, Jasmine offre un support Maven. Pour ma présentation, j’opte pour la création d’un projet squelette, via un archetype Maven. Cela se fait via cette commande :
mvn archetype:generate
-DarchetypeRepository=http://searls-maven-repository.googlecode.com/svn/trunk/snapshots
-DarchetypeGroupId=com.github.searls
-DarchetypeArtifactId=jasmine-archetype
-DarchetypeVersion=1.1.0.1-SNAPSHOT
-DgroupId=fr.devoxx
-DartifactId=chouchoutez-javascript
-Dversion=0.0.1-SNAPSHOT
Une fois ceci réalisé, nous obtenons un projet (que nous allons importer dans notre IDE préféré) ayant la structure suivante :
pom.xml
` src
+ main
| ` javascript
| ` quickstart.js
` test
` javascript
` quickstartTest.js
La partie intéressante dans le pom.xml est la déclaration du plugin Jasmine qui va permettre de lancer les tests via une commande Maven :
<plugins>
<plugin>
<groupId>com.github.searls</groupId>
<artifactId>jasmine-maven-plugin</artifactId>
<version>1.0.1-beta-6</version>
<executions>
<execution>
<goals>
<goal>generateManualRunner</goal>
<goal>resources</goal>
<goal>testResources</goal>
<goal>test</goal>
<goal>preparePackage</goal>
</goals>
</execution>
</executions>
<configuration>
<jsSrcDir>src/main/javascript</jsSrcDir>
<jsTestSrcDir>src/test/javascript</jsTestSrcDir>
</configuration>
</plugin>
En lançant la commande mvn test, on voit que le test généré par défaut par l’archetype est lancé :
------------------------------------------------------- J A S M I N E T E S T S ------------------------------------------------------- [INFO] describe The quickstart object it adds two numbers [INFO] Results: 1 specs, 0 failures
Etape #2 : Ecrire des tests
Je copie mon underscore.js dans le répertoire src/main/javascript, et nous allons le tester…
Jasmine propose une écriture assez intuitive des tests, assez proche de fest-assert. En voici un premier exemple :
describe("Mon premier test", function() {
it("should be 42", function() {
var resultat = _.max([1, 2, 3, 42]);
expect(resultat).toBe(42);
};
};
Avec Jasmine, on crée une suite de tests en utilisant le mot describe, suivi de son descriptif. Ensuite, on y ajoute une série de tests (voire on imbrique de nouvelles suites), chaque test (ou plus exactement chaque spec) étant défini par le mot clé it. On écrit le code du test, puis au moment de vérifier (i.e. de réaliser les assert), on va simplement utiliser expect suivi d’un matcher (ici toBe). Plusieurs autres matchers existent (toEqual, toBeNull, toBeGreaterThan, toContain, toBeUndefined).
A nouveau, je vérifie mes tests avec la commande Maven mvn clean test.
Voici mon fichier de tests final de la librairie underscore.js :
describe("Mon premier test", function() {
it("should be 42", function() {
var max = _.max([1, 2, 42]);
expect(max).toBe(42);
});
});
describe("Test d'underscore", function() {
var myarray;
beforeEach(function() {
myarray = [1, 2, 3];
});
it("should return 42 when asked for last item", function() {
var res = _.last([1,2,3,42]);
expect(res).toBe(42);
});
it("be true", function() {
var res = _.first([1, 2, 3]);
expect(res == 1).toBeTruthy();
});
it("should be greater than 2", function() {
expect(3).toBeGreaterThan(2);
});
it("should contains 2", function() {
expect([1, 2, 3]).toContain(2);
});
it("should have size of 3", function() {
expect(myarray.length).toBe(3);
});
it("should not be 1", function() {
var res = _.max([1, 2]);
expect(res).not.toBe(1);
})
});
describe("test with spy", function() {
it("should spy on last", function() {
spyOn(_, 'last');
var res = _.last([1, 2, 3]);
expect(_.last).toHaveBeenCalled();
expect(res).toBeUndefined();
});
});
Vous remarquerez qu’à l’instar d’un @Before de JUnit, Jasmine offre la même possibilité avec beforeEach.
De plus, Jasmine offre aussi des fonctionnalités d’espionnage.
Etape #3 : Analyser son code
Pour analyser le code JavaScript, nous allons utiliser le merveilleux outil qu’est Sonar ! Il nous faut simplement y ajouter le plugin pour le support du langage JavaScript, qui se trouve ici.
Dans notre pom.xml, nous devons ajouter ces quelques lignes, pour spécifier que le projet est de langage JavaScript, et indiquer la localisation de nos sources (et celles des tests) :
<properties>
<sonar.language>js</sonar.language>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
</properties>
<build>
<sourceDirectory>src/main/javascript</sourceDirectory>
<testSourceDirectory>src/test/javascript</testSourceDirectory>
Il suffit désormais de lancer la commande mvn sonar:sonar pour réaliser l’analyse complète, puis de se rendre sur son serveur Sonar pour en lire les résultats !
Tout n’est pas encore parfait, car nous ne disposons d’aucune information propres aux tests : pourcentage de réussite, taux de couverture du code, etc.
Etape #4 : Analyse de la couverture
Le plugin JavaScript pour Sonar sait lire les résultats des tests exécutés par js-test-driver, une autre librairie de tests JavaScript, plus orientée TDD (Tests Driven Development, ou Développement piloté par les tests). Cette librairie apporte une syntaxe très proche de JUnit, en particulier concernant les assertions. En voici un exemple :
GreeterTest = TestCase("GreeterTest");
GreeterTest.prototype.testGreet = function() {
var greeter = new myapp.Greeter();
assertEquals("Hello World!", greeter.greet("World"));
};
Bon. Mais il faut tout réécrire, et perdre ce que l’on a fait avec Jasmine du coup ? Heureusement non ! Il existe en effet un adaptateur pour exécuter des tests Jasmine via js-test-driver.
Bien entendu, nous aurions pu partir dès le début avec la librairie js-test-driver, et oublier Jasmine, mais ça n’aurait pas été fun !
Donc pour faire marcher tout cela, il faut tout d’abord copier dans un répertoire lib/ les fichiers suivants :
jasmine.js(auparavant, il était chargé via le plugin Maven, que nous n’allons plus utiliser.JasmineAdapter.js, le fameux adaptateur.
Puis, je crée un fichier jsTestDriver.conf à la racine du projet qui contient la configuration pour js-test-driver :
server: http://localhost:9876 load: - "lib/jasmine.js" - "lib/JasmineAdapter.js" - "src/main/javascript/*.js" - "src/test/javascript/*.js"
Ici c’est très simple, on indique le port où tournera le serveur js-test-driver, ainsi que les librairies à charger…
Dernière étape : modifier le pom.xml. D’abord, y supprimer les références au plugin Jasmine, devenu obsolète. Ensuite, ajouter ceci pour la dépendance vers le plugin Maven de js-test-driver :
<dependencies>
<dependency>
<groupId>com.googlecode.jstd-maven-plugin</groupId>
<artifactId>jstd-maven-plugin</artifactId>
<version>1.3.2.5</version>
<scope>test</scope>
</dependency>
</dependencies>
Puis je configure le plugin comme ceci :
<build>
...
<plugins>
<plugin>
<groupId>com.googlecode.jstd-maven-plugin</groupId>
<artifactId>jstd-maven-plugin</artifactId>
<configuration>
<port>9876</port>
<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>
On notera que certaines informations du fichier jsTestDriver.conf (comme le port du serveur) sont reprises ici. On spécifie aussi le chemin vers le navigateur utilisé par js-test-driver pour exécuter ses tests (chose inutile avec Jasmine, car ce dernier ne nécessite même pas de DOM pour exécuter les tests !).
Dernier point : j’ajoute le repository où se trouve le plugin js-test-driver :
<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>
Maintenant, pour voir si tout s’est bien passé, je vérifie que l’exécution des tests se réalise bien. J’exécute donc de nouveau la commande Maven mvn clean test :
------------------------------------------- J S T E S T D R I V E R ------------------------------------------- Firefox: Runner reset. .................. Total 18 tests (Passed: 18; Fails: 0; Errors: 0) (9,00 ms) Firefox 9.0.1 Mac OS: Run 18 tests (Passed: 18; Fails: 0; Errors 0) (9,00 ms) [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------
Bravo ! C’est presque gagné ! Il ne nous reste plus qu’à pouvoir mesurer la couverture des tests. Rien de plus simple à ce stade : il suffit d’éditer le fichier jsTestDriver.conf et d’y ajouter les 4 lignes suivantes :
plugin:
- name: "coverage"
jar: "lib/coverage-1.3.4.b.jar"
module: "com.google.jstestdriver.coverage.CoverageModule"
Je relance mvn clean package sonar:sonar, et l’analyse contient désormais les résultats des tests, mais aussi la couverture du code !
Etape #5 : Intégration continue
Lors de la présentation, j’ai manqué de temps et ai dû passé cette étape. Mais ici, rien de magique ni d’extraordinaire. En effet, comme depuis le début j’utilise des commandes Maven, les faire jouer par un serveur d’intégration continue est d’une simplicité enfantine. Je vous laisse donc le soin de jouer avec Jenkins ou tout autre serveur…
Conclusion
J’ai montré en une demi-heure environ qu’il était très simple de tester son code JavaScript, de l’analyser. Les mêmes outils sont d’ailleurs mis en oeuvre que pour le langage Java : Maven, Sonar et Jenkins.
Bref, il ne reste plus qu’à s’y mettre
Références
- Projet sur GitHub
- Slides sur Slideshare
- Abstract sur le site de DevoxxFR
- Vidéo Parleys (à venir)
]]>
Il faut venir à cette conférence, orientée Java, web, mais pas que. Il y aura du beau, du très beau monde (la preuve, j’y vais). Mais voilà, tu n’as pas ta place, ta (ton) RH n’a rien compris (ils n’ont pas Free ?) et ne veux pas t’envoyer là-bas ? Alors pourquoi ne pas essayer de gagner ton pass ?
Pour cela, tu as quatre concours qui n’attendent que toi :
- Si tu aimes faire du Java, que tu peux faire mieux que Twitter, alors lance-toi sur le Tatami ! Attention, la concurrence est déjà rude !
- Tu préfères le code JavaScript, avec du Node.JS dedans ? Alors Romain (non, pas moi), te lance un défi !
- Tu aimes les JUGs ? Va voir du côté de Nicolas de Loof, là aussi un concours t’attend…
- Tu n’as pas le temps de coder ? Tant pis. Alors il te restera la chance pour gagner un pass.
Bref, il te reste encore quelques jours pour espérer gagner un pass !
Et rendez-vous là-bas !
Start Slide Show with PicLens Lite]]>Alors parlons-en un peu (des fois que vous ne seriez pas au courant, sait-on jamais)
Mais alors, kézako ?
Devoxx, plus anciennement JavaPolis, est une conférence indépendante vieille de 10 ans, qui se tient habituellement à la fin de chaque année à Anvers, en Belgique.
Devoxx, c’est la plus grosse conférence européenne sur Java, la deuxième au monde après JavaOne (conférence « officielle » de Sun-Oracle).
Pour vous donner une idée de ce que ça représente, voici quelques chiffres qui font tourner la tête concernant l’édition de 2011:
- 5 jours de conférences, d’ateliers, de démos, d’échanges…
- 167 conférenciers,
- plus de 3200 personnes !
- sans aucun doute des hectolitres de bière (on est en Belgique quand même)
Bref, Devoxx c’est un peu le salon de l’automobile pour les développeurs Java (mais sans les hôtesses ).
L’une des annonces fracassante de l’édition 2011 a été l’arrivée de Devoxx France, fin avril 2012. Et c’est de ça dont je vais parler…
De quoi ça va causer ?
Le programme n’est pas encore finalisé (l’équipe de sélection des sujets a énormément bossé là-dessus) mais gross-modo, quatre thèmes seront abordés à Devoxx :
- Web, cloud et nosql
- Langages alternatifs pour la JVM
- Java, JavaSE et JavaEE
- Entreprises et pratiques
Bref, rends-toi sur cette page, et bientôt tu auras sous tes yeux le magnifique programme des 3 jours de la conférence…
Et moi (moi, pas toi en fait) ?
J’avais proposé deux sujets et j’ai eu l’immense honneur de les voir tous les deux sélectionnés ! Quand on sait qu’il y a eu près de 4 fois plus de soumissions que de places disponibles, ça nous met tout de suite beaucoup de pression ! Il est vrai que je n’ai pas forcément proposé dans les catégories les plus concurrentielles. Bref, mes sujets sont les suivants :
- Chouchoutez votre code JavaScript, dans les Tools in Action. Le but sera ici de montrer que l’on peut apporter autant de soin à tester et analyser son code JavaScript qu’on ne le fait déjà avec son code Java.
- TestNG, parce que vos tests le valent bien !, parmi les Quickies, où j’exposerais les avantages d’utiliser cette librairie plutôt que JUnit.
Mais… mazette, ça coûte des sous !?
Oui, c’est le prix de la liberté, de ne pas être sous le contrôle d’un grand nom de l’industrie… Il existe 3 tarifs :
- 450€ les 3 jours
- 350€ les 2 derniers jours (les conférences)
- 150€ le premier jour (les universités)
Ca peut paraitre cher (c’est pas négligeable si tu veux payer toi-même ta conférence), mais franchement, ce n’est pas du tout excessif. Il faut voir ce que cela va t’apporter : de nouvelles connaissances techniques, mais aussi humaines, de rencontrer tes idoles de toujours (la liste des speakers n’est pas encore terminée, mais il y a déjà du beau monde !). Compare cela avec une formation à 3000€ pour apprendre les bases de JSF, et tu auras compris où je veux en venir
Avec un peu de chance, tu arriveras à négocier avec ton employer de prendre cela avec ton DIF !
Et comme dans les lessives Bonux, tu as le petit cadeau qui va bien : un abonnement d’une année au site Parleys, un site regorgeant de vidéos d’anciennes conférences (dont Devoxx), de JUG, etc. pour bien apprendre plein de choses merveilleuses !
Bref, vennez nombreux à Devoxx France !!
En attendant, suivez DevoxxFR sur Twitter !
Si tu veux en savoir plus, je te laisse avec les nombreux sujets postés par Nicolas Martignole – alias le Touilleur – qui est l’un des organisateurs de la conférence…
Affiche de Devoxx France du Touilleur Express
Start Slide Show with PicLens Lite]]>Il y a quelques temps, pour un besoin personnel, j’ai utilisé l’excellent Twitter bootstrap. J’y reviendrais sans doute dans un prochain post, mais succinctement, il s’agit d’un bootstrap CSS, c’est-à-dire tout le nécessaire pour partir avec quelque chose de solide lorsque l’on démarre un site ou une application web.
Twitter bootstrap utilise (éventuellement) less. Je voulais faire un article à propos de less, mais Cédric Exbrayat l’a fait avant moi sur son blog. Il retrace parfaitement les principes de cette extension à CSS, je vous invite donc à le lire pour en savoir plus. Pour faire très court, less ajoute au CSS ce qui lui manque depuis toujours : le support de variables, de fonctions, d’imbrications de règles, etc. Le rêve pour tout développeur web qui se respecte !
Une question se pose alors : un fichier .less est un fichier .css enrichi. Mais quel est le niveau de support des IDE ? Regardons ça de plus près pour Eclipse (nous prendrons comme base la version 3.7).
Support natif
Premier test : ouvrons un fichier .less. Eclipse l’ouvre alors comme un fichier texte basique :
Configurons Eclipse pour qu’il assimile les fichiers .less à des fichiers .css. On va donc dans Préférences > General > Editors > File Associations. On y ajoute l’extension .less et on lui associe l’éditeur CSS :
De même, dans Préférences > General > Content Types, nous ajoutons l’extension .less au type CSS :
On ouvre à nouveau le fichier .less, Eclipse le reconnait comme un fichier .css désormais :
C’est déjà mieux, mais on ne bénéficie pas ici de la force de less. Il faut donc passer par un plugin.
Avant toute chose, il est nécessaire d’installer l’extension Xtext sur Eclipse. Une simple recherche sur le Market place, et zou, c’est installé :
Eclipse plugin pour Less
Le plugin Eclipse plugin pour Less est notre premier candidat. On va dans Help > Install New Software, puis on ajoute un nouveau site de mise à jour :
http://www.normalesup.org/~simonet/soft/ow/update/
On installe le plugin. Avant toute chose, il faut penser à supprimer les modifications apportées précédemment (sinon les fichiers .less seront considérés comme de « simples » fichiers .css). L’éditeur fourni avec le plugin permet donc de supporter less :
On le voit sur la capture précédente, l’auto-complétion fonctionne (la variable @linkColor a bien été reconnue). Toutefois, gros hic pour ce plugin, il ne supporte pas les références entre les fichiers (less permet en effet d’inclure des fichiers grâce à la commande @import "mon-fichier.css). Du coup, Twitter Bootstrap n’est pas utilisable en tant que tel avec ce plugin. En effet, ce bootstrap dispose d’un fichier pour les variables, d’un autre pour les mixins, d’un troisième pour les classes des tables, etc. Le plugin déclare alors forfait :
C’est d’ailleurs expliqué sur le site :
The following features are not supported in the editor:
Refactoring,
Cross-references between files.
Plugin LessCss
Testons maintenant le plugin LessCss. Ici, pas encore de site de mise à jour. Il faudra donc passer par la section de téléchargement du site. Nous téléchargeons le ZIP, déposons les .JAR contenus dans le répertoire dropin ou plugins de notre Eclipse, et finissons par le redémarrer…
Ici aussi, le support des fichiers .less est opérationnel. Toutefois, à nouveau, ce plugin nous offre un support partiel. Comme on peut le voir sur la Todo list du plugin, il reste un certain nombre de fonctionnalités à implémenter, en particulier le support du @import. Dommage !
Conclusion
Ces premiers pas à la recherche d’un éditeur solide pour less ne s’avèrent guère concluants : un support natif se limitant au CSS pour Eclipse, et deux plugins loin d’être terminés. Bref, ce n’est pas encore ça, mais gageons que le support de less par Eclipse ira en s’améliorant, tant ce framework gagne des nouveaux adeptes !
N’hésitez pas à faire part de vos trouvailles, ou aussi de votre expérience avec votre propre IDE (NetBeans, IntelliJ, etc.) !
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
propertyde 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 :
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.
]]>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
Suitemanually 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
groupsthat 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
@Categorywithout having to define aSuite. 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:
ZIPThis 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 JUnitfail()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.
]]>Ce qui semblait une tâche relativement simple s’est avérée être en réalité un chemin semé d’embuches…
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
Suitemanuellement comme on vient de le dire, mais avec le risque d’en oublier. - Ecrire des
Suitevia 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
@Categoryde 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
@Categoryde 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.
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 lefailde 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]]>- 13h30 – 14h20 : NoSQL, tour d’horizon par Claude Falguière et Grégory Paul
- 14h30 – 15h05 : Migration top chrono d’une application JEE sur le Cloud Amazon par Fréderic Sauzet et Hervé Desaunois
- 14h10 – 15h45 : Migration top chrono d’une application .NET sur le Cloud Azure par Lionel Molas et Cyril Aigoin
- 16h00 – 17h30 : Ateliers de réflexion sur le thème de la mobilité
- 17h50 – 19h50 : Coding Dojo Android, Windows Phone 7 et iPhone animés par Pascal Ognibene, Philippe Miossec et Sylvain Rousseau
Demain s’annonce donc être une journée passionnante et très instructive !
Suivez en direct mes tweets ainsi que ceux de @ValtechTechno.
]]>