Webdriver et Seleniumhq sont des outils de tests des applications web. Au départ webdriver est projet hébergé dans Google code.

Depuis le septembre, les deux projets se sont rapprochés et les jars les plus récents de WebDriver sont maintenant disponibles sur le site « Open QA ». Selenium RC (Remote Control) permet de piloter des navigateurs Web et l’API peut être utilisée avec de nombreux langages dont Java. WebDriver est une API de haut niveau qui permet soit de piloter des navigateurs soit d’utiliser une API de plus bas niveau HtmlUnit permettant de simuler un navigateur Web. Ce qui permet soit de jouer les test dans un vrai navigateur soit de les jouer sans aucune interface. Ce dernier cas est intéressant dans le cadre d’une intégration continue. Une autre particularité de WebDriver est la volonté de fournir une API simple. Le projet n’est cependant pas encore tout à fait mature, ce qui est compréhensible puisqu’il a commencé en mars 2008.

Pour l’instant pour mes projets, je continue à utiliser JwebUnit qui finalement est assez proche dans ses principes à WebDriver. Mais je pense à l’avenir que WebDriver / Selenium est une alternative valable.

Je me suis posé à nouveau le problème des tests unitaires dans le cadre d’applications EJB3/JPA, en fait deux applications. Ces applications contiennent grossièrement trois couches. La couche externe est un ensemble de stateless session beans. La couche intermédiaire sont des « queries », ce sont des stateless session beans simples effectuant des recherches dans la base de donnés. Enfin la dernière couche sont les entités des objet persistants contenant du métier.

La particularité de mes applications est bien que le métier se trouve essentiellement dans les entités et non dans les sessions beans qui eux effectue des tâches essentiellement techniques comme la gestion de la transactions. Attention, JPA est un peu limité par rapport à Hibernate et certains traitements doivent être placés au niveau des session beans.

Autre point important dans l’architecture est de respecter le principe suivant : statefull session beans > stateless session beans > entities. Ce qui signifie qu’un statefull session bean peut appeler des statefull session beans, des stateless session beans et des entités. Un stateless session bean peut appeler des stateless session beans et des entités, mais jamais de statefull session beans. Enfin, une entité ne peut appeler que des entités.

Ce dernier point rend les entités complètement indépendantes de JPA. Il est donc possible de faire les tests unitaires sans se préoccuper de la partie persistance. Ce qui renforce l’impression de framework « transparent » pour JPA.

Tester les queries et les session beans est plus complexe. Pour ces dernier, il faut un conteneur EJB3. J’utilise OpenEJB qui permet d’avoir un conteneur simple à utiliser lors de mes test. Enfin, il faut des donnés de tests. Actuellement, j’utilise des scripts SQL pour initier des donnés de test pour les queries. Enfin pour les session beans, j’utilise des méthodes qui alimentent la base de données. Ce dernier point peut devenir très lourds pour les session beans gérant les entités les plus complexes.

Ce principes d’écriture des tests unitaires fonctionnaient à près bien sans être tout à fait satisfaisant, au moins pour ma première application. En effet la base de données après les tests est polluée par les données de test introduites. Cependant, ceci devient ingérable pour ma seconde application, soit trop complexe, soit mal écrite…

J’ai appris l’existence de EJB3Unit récemment. En fait, cet outil montre quelque chose d’essentiel. Tout comme les servlets et filtres Java, les session beans sont des objets utilisables uniquement dans un conteneur (de servlets pour les servlets et les filtres). Ils nécessite un framework particulier de test. Pour les servlets, il s’agit de Cactus, pour les session beans EJB3 se serait EJB3Unit. Par contre du fait de la transparence de la persistance, EJB3Unit n’a pas d’intérêt pour les entités. J’ai bien mis le conditionnel, car ce projet semble abandonné par ces développeur depuis plus d’un an. Et la dernière version stable est incompatible avec mes applications EJB3.

Pour compléter ma présentation de IETester, j’ai fait le test sur le test ie6nomore.com. Ce site est une initiative de nombreux sites web pour inciter à l’abandon d’IE6 au profit de navigateurs plus récents et plus respectueux des normes web. En effet, ce navigateur a plus de 8 ans et il devient très coûteux de maintenir une compatibilité des sites web pour ce navigateur.

Le site w3schools fournit des statistiques montrant que IE6 représentait en juillet 2009 encore 14,4% de part de marché. Avec le rythme actuel de baisse, il pourrait encore survivre plus de deux ans. Je pense que les derniers utilisateurs sont surtout dans des entreprises qui bloquent la migration d’IE.

Ce site propose un petit morceau de code à insérer dans les sites web pour avertir les utilisateurs. Ce code utilise simplement une fonctionnalité propriétaire de IE qui est le commentaire conditionnel Html.

<!--[if lt IE 7]> Affiché si la version d'IE inférieure strictement à 7...<![endif]-->

IETester passe avec succès ce test. Les simulations d’IE5.5 et 6 affichent le message d’avertissement tandis que celles de IE7 et IE8 ignorent ce message. J’ai remarqué au passage la lenteur notable de IETester. Alors IETester est-il finalement mort-né ?

IETester et ienomore

Il vous est sans doute arrivé de pester sur Internet Explorer si vos applications tourne sur des navigateurs web. Une application qui tournait correctement sur IE 6, peut s’avérer désastreuse sur IE7.

Ce résultat est la conjonction de plusieurs erreurs. D’une part, le fait que IE soit lié fortement au système d’exploitation Windows. Ceci rend difficile la migration vers une version récente du navigateur. D’autre part, IE est resté pendant longtemps en retard sur les normes web. Enfin, l’erreur de certains développeurs est faire un développement pour une version précise d’un navigateur web. Le risque est d’utiliser des instructions spécifiques à ce navigateur. Alors qu’une application « standard » se comporte souvent correctement avec la plupart des navigateurs dont IE. Il est parfois nécessaire ensuite de retoucher l’application si on connaît le ou les navigateurs cibles du client.

Maintenant comment peut-on tester le comportement d’une application avec les différentes version de IE ? Si vous n’avez qu’une machine de test à votre disposition sous Windows, vous ne pouvez faire le test qu’avec une seule version de IE. IETeste peut (ou pourra) vous résoudre votre problème.

IETester est un outil (libre) de la société DebugBar. Cette société se présente comme la spécialiste des outils pour IE. IETester permet de simuler le fonctionnement de IE de la version 5.5 à la version 8 (5.5, 6, 7 et 8). Cet outil est disponible sous Windows uniquement et nécessite une IE.

Pour vérifier le bon fonctionnement de cet outil, j’ai fait le test acid2. La simulation de IE 5.5 et 6 donne un résultat lamentable. IE 7 donne un résultat très moyen. Enfin IE8 donne un résultat presque conforme. Ceci semble bien le résultat de la version réelle des navigateurs. J’ai regardé le test Acid3, je sais des chiffres cela fait toujours plus sérieux. Mais IE même dans sa version 8 est encore trop en retard sur genre de test.

Même s’il s’agit encore d’une version alpha assez instable avec de nombreuses limitations. Il s’agit d’un outil à surveiller de prêt en attendant une version stable.

Les deux principaux éditeurs (IDE) pour le langage Java sont actuellement NetBeans et Eclipse. Sur le site developpez.com, on trouve des sondages concernant l’utilisation des IDE Java. Les chiffres de ces dernières années montre qu’Eclipse domine largement de 55 à 60%. Le second est NetBeans avec une utilisation qui a tendance à croître au fil du temps. Cette année NetBeans représenterait 36%. En dehors de ces deux IDE, il n’y plus vraiment d’alternative.

Dans le cadre de mon travail, j’utilise une version « ancienne » d’Eclipse. La principale contrainte vient de l’existence de plugins « maison » que très peu de personnes sont capables de maintenir. Cela ne m’empêche pas d’utiliser personnellement Eclipse 4 et de m’intéresser de près des évolutions de NetBeans. La version de NetBeans actuelle est la 6.5 datant du 19/11/2008. Une version 7.0 est en cours de développement.

Voici, quelques plus de NetBeans. Premièrement, la facilité de création de projet de type « Struts » version 1. Ensuite, il existe un module UML disponible pour NetBeans. Dans la version précédente de NetBeans 6.0, ce module était intégré dans la version de base. Il faut maintenant le télécharger si on le désire. Il faut aller dans le menu Tools\plugins pour ajouter les plugins désirés. On peut également rapidement le plugin pour le framework Wicket. Mais il manque forcement toujours quelque chose, par exemple je n’ai pas trouvé de plugin récent pour tapestry.

Un petit aller retour en la France et Bruxelles m’a permis de trouver quelques revues et journaux gratuits permettant de lire dans quelques langues étrangères.

D’abord le journal « Flanders Today » est facilement disponible à Bruxelles. Il s’agit d’un journal hebdomadaire en anglais soutenu par le gouvernement flamand. Il est possible de le recevoir gratuitement chez soi pendant un an même hors de la Belgique.

Ensuite Brussel Deze Week ou BDW est un journal en néerlandais. Ce journal concerne l’actualité de Bruxelles. Il est également facilement disponible à Bruxelles. L’abonnement est gratuit uniquement pour les Bruxellois. Le coût reste cependant modeste pour les autres belges (15 euros par an).

Enfin, je ai trouvé le dernier dans le train. En effet, Thalyscope est un bimenstriel (tous les deux mois) en français, néerlandais, allemand et anglais. La dernière langue peut agacer un peu, depuis quand Thalys désert Londres ? Mais je ne connais pas de revue aussi polyglotte.

La commande « mvn site » permet de générer l’ensemble des rapports dans le répertoire target\site du projet. La page d’accueil est target\site\index.html. Rappelons que le contenu du répertoire target est généré par Maven. L’équipe de développement ne doit rien y placer manuellement. Son répertoire de travail est src. Enfin la commande mvn clean détruit le dossier target et son contenu. Cette commande reste utile lorsque Maven commence à avoir quelques problèmes.

Il est possible de configurer l’apparence du site. Je l’admet ce n’est pas fondamentalement important pour un petit projet, ou un petite structure. En plus, cela ajoute des fichiers de configuration. Un principe important de Maven est « convention over configuration ». Suivant ce principe, si une configuration n’est pas préciser,Maven utilise la convention par défaut. Ceci permet de réduire au maximum les fichiers de configuration au maximum. Notons qu’il s’agit un mouvement profond dans les outils de développement (comme Ruby on Rails)

Maintenant une grande organisation désire suivre une convention de présentation. C’est possible, il suffit d’ajouter un fichier site.xml dans le répertoire src/site. Il est possible que le dossier « site » n’existe pas encore. Ceci montre encore la puissance de Maven. Voici un exemple de fichier site.xml.


<project>
   <body>
      <links>
         <item name="Apache" href="http://www.apache.org/" />
         <item name="Maven 2" href="http://maven.apache.org/"/>
      </links>
      <menu ref="reports" />
   </body>
   <skin>
      <groupId>org.apache.maven.skins</groupId>
      <artifactId>maven-stylus-skin</artifactId>
      <version>1.0.1</version>
   </skin>
</project>


La partie link permet de créer des liens vers les sites sur l’entête des pages (en général en haut à droite). Le menu reports crée le menu concernant les différentes métriques et rapports (javadocs, rapport de test, couverture de code) définis dans le noeud reporting du fichier pom.xml. La partie skin du fichier site.xml permet de personnaliser l’apparence. Il existe sur les dépôts Maven 4 skin :
maven-classic-skin (version 1.0), maven-default-skin (version 1.0), maven-stylus-skin (versions 1.0 et 1.0.1) et maven-application-skin (version 1.0-SNAPSHOT).

Voici des impressions écran du même rapport avec ces 4 skins.

Maven2 est un outils fascinant pour les personnes travaillant sur les projets Java. Il permet de gérer en premier les dépendances du projet. Mais il fournit d’autres fonctionnalités comme la génération de rapports (recherche de bugs, suivi de conventions de code, métriques), ceci en ajoutant quelques lignes de déclaration. En fait il prépare l’industrialisation des développements.

Les rapports sont générés suivant le cycle normal de Maven, par la commande : « mvn site:site ». Pour la génération de ces rapports, je conseille fortement d’utiliser Maven en ligne de commande et non le plugin m2 d’Eclipse (pour les utilisateurs de cet IDE). En effet, il existe trop de petits bugs dans ces plugins Maven pour Eclipse. Le rapport par défaut prévoit plusieurs informations de bon sens (about, project license, project team) qu’il est possible de renseigner dans le fichier pom.xml du projet.

Il est possible d’ajouter des plugins pour obtenir des rapport supplémentaires. Ceci se fait dans le noeud « reporting » du fichier pom.xml. Le plugin proviennent essentiellement du projet maven lui-même ou du projet mojo.codehaus.org. La déclaration est très simple en général, il suffit d’indiquer le groupId et l’artifactId du plugin. Les maniaques peuvent ajouter le numéro de version. Cette simplicité contraste avec le travail fait avec Ant.

Les premiers plugins que je propose d’utiliser sont en fait des plugins simples qui ne correspondent pas vraiment à des rapports classiques mais à des outils plus généraux. Le premier jxr (ou Xref) met simplement sous forme HTML le code source et celui des tests unitaires. Ce code source sera utilisé par d’autres plugins pour indiquer explicitement les lignes de code en problème. Ainsi, si un plugin (comme checkstyle) dit que telle ligne de code de telle classe ne respecte pas une convention de code, il est toujours plus agréable d’avoir un lien sur la ligne en question. La déclaration de ce plugin dans la partie reporting est :


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-jxr-plugin</artifactId>
   <version>2.1</version>
</plugin>


Le second plugin est celui qui génère la javaDocs. Il est vrai que le format de la javaDocs est un peu vieillot mais il est largement utilisé dans les projets Java. Ensuite Eclipse permet de générer cette javaDocs, mais l’avantage de l’automatisation et l’intégration dans les rapports.


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-javadoc-plugin</artifactId>
   <version>2.5</version>
</plugin>


Le troisième est également un plugin « simple ». Il s’agit de Surefire qui génère un rapport des tests unitaires dans le cadre des frameworks JUnit ou TestNG. L’écriture des tests unitaires est un point important pour un développement de qualité. Il faut cependant admettre qu’avoir le bon niveau de test n’est pas évident. Un détail important Maven ne semble pas exécuter les tests unitaires pour JUnit dans le même ordre que le plugin JUnit pour Eclipse. En soit, c’est une bonne chose, car les tests unitaires doivent être indépendants les uns des autres.


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-report-plugin</artifactId>
   <version>2.4.3</version>
</plugin>


Le quatrième plugin que je propose analyse le code, de manière simple. Il s’agit de taglist. Il va repérer les tags //TODO ou @todo laissés dans le code. Il est possible d’ajouter d’autres tags (par exemple @deprecated ou //FIXME) en configurant le plugin. Un conseil en passant, les //TODO sont généralement créés par les générateurs de code. Je ne les efface pas mais je remplace par des //DONE. Dans l’exemple suivant je configure explicitement 4 tags


<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>taglist-maven-plugin</artifactId>
   <version>2.3</version>
   <configuration>
      <tags>
         <tag>TODO</tag>
         <tag>FIXME</tag>
         <tag>@todo</tag>
         <tag>@deprecated</tag>
      </tags>
   </configuration>
</plugin>


Il existe d’autres plugins comme checkstyle, cobertura, pmd, JDepend. A vos de les étudier et de voir ce qui convient à votre projet.

J’avais déjà signalé l’existence d’un benchmark des moteurs de JavaScript dans le projet webkit (sunspider), le coeur du navigateur Safari. Le résultat est un temps moyen pour effectuer différentes fonctions JavaScript. Naturellement, on peut suspecter que ce benchmark favorise un peu le navigateur Safari. Mais ce dernier n’est que 4ème sur 8. Il est même repassé derrière Opera. Google Chrome est incontestablement premier et Internet Explore dernier.

Un second benchmark est disponible sur le site du projet V8, le moteur de JavaScript du navigateur. Ici, le résultat est un nombre relatif. Le principe est que plus ce chiffre est grand plus le moteur est performant. Ceci a l’avantage d’être indépendant de l’ordinateur sur lequel s’effectue le test. Là Google Chrome écrase ses concurrents. Cependant, le classement n’est pas exactement le même.

Cela fait plusieurs fois que je me suis posé la question s’il est correct de parler de différentes versions du langage script. Cette question m’est revenue suite à la visite du site BrowserHawk. Ce site teste les différentes capacités du navigateur web utilisé (détection du navigateur, temps de réponse). Il fournit une version langage JavaScript utilisé par le navigateur.

J’ai fais le test avec 8 navigateurs pour Windows que je considère comme « pertinents » : navigateur complet (pas une simple surcouche), mis à jour régulièrement. Ma liste est donc : Internet Explorer, Firefox, Safari, Flock, Google Chrome, K-Meleon, SeaMonkey et Opera. J’ai pris les dernières versions stables de ces navigateurs. Je suis toujours à la recherche d’autres navigateurs qui respectent les critères décrits précédemment. Voici les résultats obtenus :

Les résultats montrent que les versions de JavaScript sont relativement récentes. Ils semblent cohérents (même résultat pour SeaMonkey et K-Meleon). Le second test est l’utilisation explicite de la version de Javascript dans une page Html comme ceci :


<script language= "JavaScript1.2">.../...</script>


ou autre manière plus standard (?)


<script type="text/javascript;version=1.2">
.../...
</script>


La seconde version de cette technique, ne fonctionne pas pour 3 navigateurs. Finalement, j’ai un gros doute sur l’interprétation de ce code. Signifie-t-il vraiment que le cette partie de script est interprétée si le navigateur supporte au moins cette version de JavaScript ? Opera ne serait-il pas un peu gros “vantard” ? Les résultats sont en fait très différents de BrowserHawk.

Une meilleure solution serait de tester la version de JavaScript en utilisant des fonctionnalités spécifiques à chaque version. JavaScript est normalisé en tant que ECMAScript, et le site de la fondation Mozilla donne les correspondances dans le tableau qui suit. Ce qui pose la question des versions intermédiaires qui seraient spécifiées uniquement par Mozilla.

Sur le site de Mozilla dit MDC « Mozilla Developer Center », on trouve plus ou moins difficilement les différences entre les versions successives JavaScript. Ce qui m’a permis d’écrire un script testant la version courante du JavaScript. Ce script permet de tester les version 1.0, 1.1, 1.2, 1.3, 1.5, 1.6, 1.7, 1.8 et 1.9.1. Ce script donne avec les 8 navigateurs de références.

Pour valider mon script, je l’ai testé avec les différentes version de Rhino. Il s’agit d’une implémentation en Java du moteur de JavaScript de Mozilla. Attention, il n’est pas utilisé dans les navigateurs Web comme Firefox mais est un reste d’un ancien projet abandonné d’un navigateur web en Java. La version Rhino 1.5R5 correspond à la version 1.5 du JavaScript, la version 1.6R7 correspond à la version 1.6 du JavaScript, et enfin 1.7R1 à la version 1.7. Ceci fonctionne correctement avec mon script. Utiliser Rhino pour exécuter du JavaScript est en effet simple. Il suffit d’utiliser la commande qui suit (test.js est mon script de test). Il existe une méthode main dans ce jar.


java -jar js.jar -f test.js


Au final, on voit qu’il existe un flou dans les différentes version du langage JavaScript mais qu’une version 1.3 ou 1.5 semble un compromis acceptable pour l’instant. Notons bien ici que je parle du coeur du langage et non de l’implémentation du DOM, l’accès aux éléments d’une page Web.

Voici le fichier test.js

function testVersion() {
var myArray = ['a', 'b', 'a', 'b', 'a'];
var res="";
var myNumber=2489.8237
var myString="eer";

}
testVersion();