Archive for novembre 2008

Selenium RC (Remote Control)

novembre 11, 2008

Selenium RC fait partie d’un ensemble d’outils de test des applications web. Parmi ces outils, il existe un outil particulièrement intéressant Selenium IDE.

Ce dernier est un plugin pour Firefox permettant d’enregistrer et de lancer des scripts de test des applications web. Le langage utilisé par défaut est propriétaire, exportable au format HTML. Mais ce plugin peut servir avantageusement de « recorder » pour la version Java. En effet, il suffit d’aller dans le menu de Selenium IDE « option\format » est de choisir le langage Java. En effet, il est parfois au début très difficile de passer du langage de commande au langage Java.

Il est possible d’écrire les tests avec Selenium à l’aide du langage Java. Un framework de test comme JUnit permet d’organiser ces tests. Au début, j’ai été tenté d’utiliser un autre framework de test que JUnit3 (JUnit4). Mais finalement le Selenium RC est une librairie de test intimement liée à JUnit3. Il est préférable de suivre le choix des concepteurs. La classe SeleneseTestCase étend la classe TestCase de JUnit. Elle contient une variable selenium de type Selenium initialisée lors de la méthode setup. Cette variable représente le navigateur web.

La classe SeleneseTestCase fournit des assertions supplémentaires commençant par verify comme verifyEquals. Quelle est la différence avec le assertEquals de TestCase ? En fait, ces méthodes font échouer le test si une assertion n’est pas respectée lors du tearDown, donc sans arrêter le script de test. Attention, ceci est « anti test unitaire », mais reste acceptable ici. En effet les tests des applications web ne sont pas en soit des tests unitaires, mais des tests de plus haut niveau.

Selenium RC se base sur un « serveur » ou un « proxy applicatif ». Pour démarrer ce serveur, le plus simple est d’utiliser le jar selenium-server*.jar, avec la commande « java -jar selenium-server.jar ». Le serveur démarre par défaut sur le port 4444. Il faut éviter de le changer car il s’agit du port qu’utilise la classe SeleneseTestCase. Dans un autre article, je décrirai comment le démarrer de manière programmatique.

Le code du test simpliste de démonstration avec le moteur de recherche Google peut être le suivant:


package com.petitteckel.seleniumdemo;

import com.thoughtworks.selenium.SeleneseTestCase;

public class GoogleTest extends SeleneseTestCase {


 public void setUp() throws Exception {
  //setUp("http://www.google.fr/", "*custom E:\\program\\mozilla.org\\SeaMonkey\\seamonkey.exe");
  setUp("http://www.google.fr/", "*iexplore");
 }


 public void testGoogle() {
  selenium.open("http://www.google.fr");
  verifyEquals(selenium.getTitle(),"Google");
  selenium.type("q", "Selenium");
  selenium.click("btnG");
  selenium.waitForPageToLoad("5000");
  verifyEquals(selenium.getTitle(),"Selenium - Recherche Google");
 }
}

La chaîne de caractères « *iexplore » représente le type de navigateur à utiliser. En effet Selenium RC pour effectuer les tests pilote les navigateurs existants. Il a donc besoin de la présence de ces logiciels. Cela pose des contraintes, par contre a l’avantage d’être fidèle à ces navigateurs. Au niveau des variables prédéfinies, il en existe 11 correspondant à des navigateurs ou des configurations de navigateurs, *iexplore pour Internet Explorer, *firefox pour Firefox, *opera pour Opera. Pour voir la liste de ces variables, il suffit de mettre *nimportquoi au niveau de cette variable et la console du serveur va la refuser et afficher la liste des variables possibles. L’utilisation de ces variables devrait permettre l’utilisation des navigateurs sans les reconfigurer, dans la pratique cela ne marche pas très bien, voire pas du tout. La solution de secours est d’utiliser la chaîne *custom.

Il faut dans ce cas faire suivre *custom du chemin exact du navigateur. Au niveau du navigateur, il faut préciser que le proxy est localhost port 4444. Cela fonctionne avec tous les navigateurs installés sur mon poste Windows (de Flock à Safari en passant par Google Chrome). Mais cela risque de poser un problème si la connexion vers l’application testée passe également par un proxy.

Enfin, il est possible d’utiliser Maven, pour la gestion des dépendances dans le projet Java. Je mets dans l’exemple plus bas les dépendances pour la version 1.0-beta-1 (la dernière). Par défaut, le jar junit3.8.1.jar est mis dans le projet. Ceci confirme bien ce que j’ai expliqué un peu avant.


 <dependency>
  <groupId>org.openqa.selenium.client-drivers</groupId>
  <artifactId>selenium-java-client-driver</artifactId>
  <version>1.0-beta-1</version>
 </dependency>
 <dependency>
  <groupId>org.openqa.selenium.core</groupId>
  <artifactId>selenium-core</artifactId>
  <version>1.0-beta-1</version>
 </dependency>

Au final, je trouve que Selenium RC est un outil intéressant mais pas encore stabilisé, donc difficile à généraliser au niveau d’une entreprise.

L’outil d’automatisation Maven2

novembre 8, 2008

Maven est un outil dont la notoriété et l’utilisation augmente dans le monde Java. Son utilisation croit également dans le cadre de l’entreprise. D’autre part, son utilisation se répand largement dans les projets libres. Il facilite largement la tâche de recompiler un projet libre à partir du code source. Je tenterai ici d’expliquer pourquoi.

Il s’agit notamment d’un outil d’automatisation des tâches, même si ce point de vue est un peu réducteur. Il remplace avantageusement Ant pour la partie automatisation. Dans cette présentation, je me limite à Maven2. En effet, Maven1 était un Ant un peu amélioré sans intérêt réel maintenant.

Maven comme Ant permettent d’automatiser les tâches dans un projet Java, comme la compilation, la génération d’archive, de rapport. Dans Ant, on définit certaines tâches, cela ressemble un peu à de la programmation. C’est donc bien adapté à l’état d’esprit d’un développeur. Mais finalement, on a l’impression redéfinir la roue à chaque fois et les scripts Ant peuvent devenir très longs, peu normalisés et difficiles à comprendre par une personne étrangère à l’équipe projet. Quant à Maven, il se base sur un principe complètement différent de Maven. On ne déclare pas de tâches, elles sont prédéfinies. C’est assez logique. Un projet Java doit être compiler, il devrait être testé, il doit permettre la création d’une archive comme un jar ou un war pour être utilisé facilement par d’autres projets. Donc la commande « mvn test » exécute les tests unitaires, « mvn package » génère l’archive associée au projet, et ceci pour tous les projets utilisant Maven. Il est possible de générer avec Maven, les rapports associés aux outils de qualité comme checkstyle et cobertura.

Comment fonctionne alors ce magique outil Maven ? Le développeur définit dans le fichier pom.xml la structure du projet. Je ne déclare pas les actions à effectuer sur le projet mais comment est structuré le projet. Cette approche déclarative n’est pas forcément la plus proche de l’état d’esprit du développeur mais est ici beaucoup plus efficace. Un autre point diminue fortement la taille du fichier pom.xml, Maven se base sur des conventions. Le code source se trouve par défaut dans le répertoire src/main/java. Il est toujours possible de le placer ailleurs mais finalement il est mieux de suivre les conventions. Le seul cas où il reste utile de surcharger les conventions est lorsqu’on reprend d’anciens projets archivés sous CVS. Le déplacement d’un fichier avec CVS fait perdre l’historique.

Maven gère également les dépendances entre projets avec les versions. Un projet java classique va utiliser le framework de test Junit (version 3 ou 4), la librairie log4j pour la gestion des traces techniques. On déclare explicitement les dépendances et leurs portées (test, compile, runtime). Ceci est sans doute une réponse provisoire au grand désordre qu’est la non gestion des dépendances dans le monde Java (et je suis très poli ici : c’est le vrai B***).

Il demeure cependant quelques problèmes lors de l’utilisation de Maven. Le premier est le manque d’intégration dans Eclipse. Ce problème était important il y a quelques temps. Maintenant, il existe deux plugins m2eclipse et q4e. J’utilise le premier dans mon activité professionnelle, ceci de plus en plus. Le second q4e est un projet Google. Il apparaît plus ambitieux que m2. Il propose notamment une vue graphique des dépendances. Maintenant, l’installation par le site update ne fonctionne pas. Je ne le conseille pas un premier temps et je vous propose m2.

Les plugins ne font pas tout. Il existe un manque dans Eclipse au niveau de la hiérarchie des projets. Tous les projets Eclipse sont au même niveau. Tandis que Maven autorise des hiérarchies de projets. En fait ceci est imposé par Maven du fait qu’un projet Maven correspond à un seul artefact (pas deux ou plusieurs). Ceci risque d’engendrer un nombre important de projets Eclipse. Notons qu’Eclipse n’a pas de notion de portée des dépendances. Donc si vous utiliser Junit, une librairie Junit*.jar apparaît dans la liste des dépendances alors qu’avec Maven on peut indiquer que cette dépendance ne concerne que la partie des tests, et non l’utilisation de l’archive dans un autre projet.

Autre point délicat, je découvre régulièrement des petits bugs dans les plugins Maven de métriques et de qualité du code.

Un nom de domaine pour la Flandre ?

novembre 1, 2008

Le ministre-président Kris Peeters veut créer un nom de domaine de premier niveau (TLD pour Top Level Domain) pour la Flandre. Un TLD est une extension comme le .be pour la Belgique ou le très courant .com qui apparaît dans les applications de l’internet comme l’adresse web ou l’adresse mail. Pour un pays ont parle de ccTLD (country code TLD) et pour un nom de domaine ouvert à tous de gTLD (generic). Un troisième groupe forme les sTLD pour les noms de domaines limités à une communauté, dits « commandités »

L’ICANN l’association qui gère les noms de premier niveau avait une politique très prudente de ces noms. Les pays ont d’office un nom de premier niveau sur deux lettres suivant la norme ISO 3166-1 comme le .be ou le .fr. Mais, il n’y avait rien pour les subdivisions des pays ou les grandes métropoles…

Mais en 2005, l’ICANN a autorisé le sTLD .cat pour la communauté catalane (langue et culture, par pour la région espagnole). Suite à cette décision sans doute un peu hasardeuse, de nombreuses régions se sont mises à rêver de leur propre nom de domaine de premier niveau. Une association milite pour un .bzh pour la Bretagne. D’autres initiatives font la promotion d’un .sco pour l’Ecosse et d’un cym pour le Pays de Galles. Les peuples celtiques abusent-ils de l’alcool ?

Cette année, l’ICANN a annoncé une certaine libéralisation des noms de domaine de premier niveau pour un démarrage effectif en 2009. Juste un petit détail supplémentaire, le budget est estimé à 100 000 euros. En fait d’autres sources parlent d’une somme un peu plus élevée : 200 000 Dollars américains.

Quel est vraiment l’intérêt d’un tel nom ? Les noms de domaine génériques (ouvert à tous) lancé vers 2001 comme le .biz ou le .info ont eu des succès mitigés. Des sTLD comme le .mobi ou le .tel finissent par être ouvert à tous. Je pense que pour les grandes régions cette idée n’est pas si farfelue qu’elle n’y paraît. Maintenant, quel nom de domaine pour ma région ? Le .vl est libre mais ce nom n’est pas autorisé par le règlement de l’ICANN (la Flandre n’est pas un état indépendant). Les propositions sont .vla .vln .vlaanderen .fla…

Il est beau mon petit lion...

Il est beau mon petit lion...