Archive for août 2007

browsrcamp capture de site web sous Mac OS X

août 26, 2007

Le site browsrcamp propose des captures d’écran avec le navigateur Safari sous Mac OS X. En effet même si ce navigateur existe maintenant pour Windows, rien ne vous garantit que le résultat sous Windows est identique sous Mac (ce serait trop facile). Il existe un service payant proposant 11 navigateurs sous Mac OS X. On découvre ainsi les navigateurs spécifiques au Mac OS X : Camino, iCab, OmniWeb et Shiira.

Publicités

Watij (version java de Watir)

août 26, 2007

Il existe des outils de tests des application Web utilisant des langages autre que le Java. Par exemple Watir pour « Web Application Testing In Ruby » utilise le langage Ruby. Naturellement il s’agit d’un outil libre (licence BSD).

Watir pilote le navigateur Internet Explorer, il s’agit bien de tester des applications web à travers un véritable navigateur. Cette approche est bien différente de HttpUnit ou HtmlUnit qui sont des API java simulant un navigateur web.

Cette approche est intéressante car le déroulement du test est visuel Internet Explorer s’ouvre, il nous montre les résultats. L’inconvénient est que le test nécessite ce navigateur, cette approche est moins universel que HtmlUnit qui permet de « se présenter » au serveur comme un navigateur donné ou de choisir la langue de ce dernier. la dernière version stable est la 1.4.1 datant du 21/08/2005. Mais le développement continue et des versions de développement 1.5.1.* existent et datent de 2007.

Pour combler le manque d’universalité de Watir, il existe des versions de cet outil pour les autres navigateurs comme SafirWatir (dernière version 0.2.5 du 04/07/2007) pour le navigateur Safari sous Mac, et FireWatir (dernière version 1.1 du 26/07/2007) pour Firefox 1.5 et suivant. Des détails sur Firewatir existent sur le blog d’Angrez, un membre de ce projet.

Même si ces projets me semblent intéressants, je suis réticent à devoir apprendre un nouveau langage de programmation (Ruby). Heureusement pour moi, il existe un portage de Watir en Java appelé Watij (Web Application Testing Tool in Java). attention Watij nécessite le jdk 1.5.

Après une phase de développement importante en 2006, le projet semble fortement ralenti depuis. Il existe un groupe de discussion Google sur le sujet. La dernière version est la 3.1.0 datant du 19/06/2007. Malgré des doutes sur le support de IE 7, le projet semble pleinement fonctionnel.

Maintenant que faire de cet outil ? Dans un premier temps HtmlUnit reste mon outil préféré. Et écrire des tests avec un outil comme Watij dont on ne connaît pas l’avenir est risqué. Cependant ce dernier permet de préparer des démonstrations d’application web assez intéressantes.

Exemple de code, dans un test unitaire JUnit avec une page contenant un formulaire login/mot de passe. Le code est simple à comprendre

public void testlogin()	{
	IE ie=new IE();
	try {
		ie.start("http://monsiteweb.com");
		ie.textField(SymbolFactory.name,"ipLogin").set("p");
		ie.textField(SymbolFactory.name,"ipPasswd").set("p");
		ie.button(SymbolFactory.id, "btSubmit").click();
		ie.maximize();
	} catch (Exception e) {
		fail("Exception "+e);
	}
}

Compiler les sources de HtmlUnit

août 19, 2007

Il est toujours intéressant d’essayer de recompiler les projets libres, surtout lorsqu’il s’agit de projet de taille moyenne. HtmlUnit est un projet libre écrit en java, le langage de programmation que j’utilise habituellement. En plus, il s’agit d’un outil que j’utilise actuellement dans le développement d’une application web. Enfin le projet semble de qualité avec plusieurs développeurs différents, des métriques de code, des conventions d’écriture de code et des tests unitaires.

Pour rappel, htmlUnit est « un navigateurs web pour programme Java ». Sur le site officiel, on peut lire la phrase suivante « HtmlUnit is a browser for Java programs ». Il s’agit d’une API qui simule un navigateur Web. Associé avec JUnit, HtmlUnit permet de faire des tests unitaires des applications web côté présentation. Ici, j’utilise la dernière version (1.13) du projet.

Le projet utilise Maven, mais dans l’exemple suivant je vais utiliser Ant. Ant permet d’automatiser les taches pour les projets Java. Il faut utiliser la dernière version de ant (1.7.0) pour ce projet. Maven va beaucoup plus loin en gérant les dépendances. Une fois que le projet est téléchargé, décompressé, on repère facilement qu’il y a un fichier build.xml, le fichier nécessaire à ant pour savoir les différentes tâches à effectuer. Dans le répertoire où se trouve ce fichier, il suffit de passer la commande « ant », et espérer avoir le résultat « build successful » et surtout d’obtenir un nouveau fichier jar « htmlunit.jar ». Mais la première fois vous aurez sans doute le résultat « build failed » et de nombreuses erreurs.

Le problème est qu’il manque les jars nécessaires à la compilation du projet. Le site du projet détaille les dépendances. Il est donc possible de rechercher et télécharger les jars nécessaires à la compilation. Cependant, ce n’est pas utile car tout est déjà dans le fichier de configuration de ant (build.xml). Dans celui-ci, les taches sont définis par les balises « target ». Il existe des dépendances entre tâches avec l’attribut depends, c’est à dire les tâches à effectuer avant de faire la tâche, par exemple avant de créer le jar, il faut effectuer la compilation. Il existe une tâche « get-jars » qui va télécharger les jars nécessaires aux autres tâches. Donc il suffit de passer la commande « ant get-jars ». Bien sûr une connexion à Internet est nécessaire. Il faut faire également attention au éventuel blocage du aux firewall. Vous pouvez vérifier le bon déroulement de cette étape avec la création du répertoire ant-jars, et la création de deux sous-répertoires contenant les jars pour le projet et les jars pour les tests unitaires.

Maintenant, nous allons tenter de compiler les sources et d’effectuer la commande « ant-compile ». Cette étape compile les sources du projet et les sources des tests unitaires. Vous pouvez vérifier le bon déroulement de cette étape en vérifiant la création d’un répertoire ant-target et par le fait qu’il contienne les fichiers compilés des sources et des tests.
Maintenant, passons à l’étape checkstyle. il s’agit d’un outil de contrôle de code. Il vérifie le bon respect des conventions de code. Le sujet des conventions de code est un sujet assez vaste notons que Sun a publié ses règles de bonne écriture du code Java. Donc utilisons checkstyle avec la commande « ant checkstyle ». Si vous êtes sous Windows vous serez noyés par les messages « il manque un caractère NewLine à la fin du fichier ». Ceci vient que les développeurs utilisent des fichiers de type Unix. Il faut corriger le fichier checkstyle.xml et préciser que les fichiers utilisent la convention de fin de ligne Unix.

La règle :

<module name="NewlineAtEndOfFile/">

devient :

<module name="NewlineAtEndOfFile">
	<property name="lineSeparator" value="lf"/>
</module>

Maintenant, cette étape doit se passer sans problème.

L’étape suivante est d’effectuer les tests unitaires. La commande est ant junit. Sur mon poste, 12 tests ne passent pas. Je n’ai pas cherché à voir d’où venait ce problème. Simplement, notons que ce projet utilise gsbase (http://gsbase.sourceforge.net/) une librairie qui complète JUnit. Par exemple, il existe la classe « orderedTestSuite » qui assure que les tests soient effectués dans un ordre déterminé. Dans ce cas sont-ils encore unitaires ?

Enfin, la dernière étape est de créer le jar. Il suffit de passe la commande « ant jar » ou « ant » seule. J’ai modifié un peu l’attribut depends de la tache jar du fait que le test junit échoue et qu’apparemment checkstyle a besoin du résultat de la compilation pour analyser les sources de la partie des tests.

Donc, il y avait :

depends="clean,checkstyle,compile,junit"

J’ai mis à la place :

depends="clean,compile,checkstyle"

Maintenant, le jar est créé. Il est possible d’utiliser et de commencer à faire quelques modifications simples, comme par exemple ajouter des constantes supplémentaires. Autre point , il est toujours possible d’ouvrir le projet sous Eclipse. Ce dernier découvre facilement la configuration ant et peut configurer en partie le projet.

Un tout dernier point, bravo aux membres de ce projet pour la qualité de ce projet.

HtmlUnit nouvelle version (1.12) et soumission de formulaires…

août 12, 2007

La nouvelle version d’HtmlUnit est sortie le 10 août 2007. Il s’agit de la version 1.12. la deuxième mise à jour de l’année. Donc le projet reste bien vivant.

J’ai voulu la tester assez rapidement, car j’utilise cet outil dans le développement d’une application web. La mise à jour n’a pas posé de problème et a même corrigé des petits bugs gênants. Le seul changement notable se situe dans la gestion de la soumission des formulaires web.

Les méthodes « submit » de la classe HtmlForm représentant un formulaire ont été mises en dépréciées. Il faut donc décrire un « click » sur un bouton, par exemple rechercher le bouton submit et le cliquer. Bizarre, car dans un formulaire web, la soumission peut se faire simplement en appuyant sur le bouton enter du clavier. Après plusieurs, j’ai pu vérifier que le enter et le click sur le bouton submit donnent le même résultat. Notamment que l’on peut mettre des attributs name et value au bouton submit. Cette valeur est transmise au serveur comme les autres valeurs du formulaire. Là où cela devient subtile est qu’il est possible de définir plusieurs boutons submit, et de savoir grâce à la valeur associée lequel est cliqué. Par contre le enter semble envoyer systématiquement la valeur du premier bouton submit.

Le langage Javascript étendre les classes prédéfinies

août 12, 2007

Le langage JavaScript peut apparaître comme « exotique ». Il ne se base pas sur le principe de la programmation orientée objet classique comme celle du C++ ou du Java. Son principe est la programmation orienté objet par prototype. Je ne désire pas ici aller dans les détails de ce principe mais juste faire quelques illustration. Par exemple le mot clef « class » n’existe pas. En fait on ne définit que des objets qui éventuellement permettent de définir d’autres objets.

JavaScript est essentiellement utilisé pour créer des scripts dans les navigateurs web. Il faut bien distinguer dans ce cas le JavaScript le coeur du langage et du DOM un ensemble d’interfaces pour interagir avec le navigateur. Ici, je m’intéresse au JavaScript. Pour étudier ce langage, je travaille avec Rhino ce qui explique la présence de « print » dans le code.

L’exemple suivant montre comment étendre les classes prédéfinies dans le langage JavaScript comme l’objet String ou l’objet Date. il s’inspire fortement de deux d’articles de Thierry Templier publiés sur le site developpez.com .

function inheritance(destination, source) {
  for(var element in source) {
    destination[element]=source[element];
  }
}

inheritance(Date.prototype,{
  showWithSeparator: function(separator) {
    var year=1900+this.getYear();
    var month=this.getMonth()+1;
    var day=this.getDate();
    
    if(month<10)
      month="0"+month;
    
    if(day<10)
      day="0"+day;
    
    return day+separator+month+separator+year;
  }
});

var myDate=new Date(2005,12,23);
print(myDate.showWithSeparator("-"));

var myDate2=new Date(2005,2,3);
print(myDate2.showWithSeparator("/"));

le plugin Eclipse ResourceBundle Editor

août 12, 2007

Eclipse est un éditeur formidable à condition d’avoir une machine très puissante. Régulièrement on découvre des plugins supplémentaires qui permettent de faciliter la vie des développeurs.
Le plugin « ResourceBundle Editor » ou rbe est un plugin qui facilite de développement de la partie d’internationalisation des applications. Pour rappel, il existe deux stratégies pour internationaliser les applications : soit l’internationalisation statique, soit l’internationalisation dynamique. Dans une internationalisation statique chaque vue doit être réécrite dans les différentes langues cibles. Par contre dans l’internationalisation dynamique la vue reste unique, la traduction se fait au niveau des mots ou des groupes de mots. Ils sont remplacés dans la vue par des clefs et de fichiers rassemblent leur traduction dans les différentes langues. La stratégie dynamique semble la plus courante mais peut être mal adaptée dans certains cas contenant des textes très long.

En fait, il ne faut pas parler de langue mais de paramètres régionaux (transcription en français de la notion de « locale » en anglais). Il est possible de devoir distinguer le français de France, du français du Canada. En Java nous aurons la locale fr_FR et fr_CA.

le plugin rbe permet de visualiser facilement les correspondances dans les différentes « locales » des clefs définies. Egalement, les clefs peuvent être hiérarchisées en utilisant un arborescence dans les noms des clefs avec le point comme séparateur.

La version actuelle est la 0.7.7 datant du 06/02/2007. Voici un petit exemple :

ResourceBundle Editor

JTidy portage de Tidy en Java

août 7, 2007

Pour tester la validité des pages sur mes applications web dynamiques, j’utilise habituellement un plugin Firefox « HTML Validator » et je survole globalement le site en espérant avoir une belle coche verte partout. Il existe bien des outils de validation officiel comme celui du W3C, mais ils sont peu pratique pour des sites web dynamiques.

Récemment, j’ai tenté d’intégrer la validation des pages web à mes tests unitaires côtés présentation. Pour ces tests unitaire j’utilise les API java htmlUnit qui sont une extension de JUnit. Globalement, je veux une méthode qui teste que la page HTML reçue est valide. Pour effectuer cela, j’ai utilisé JTidy le portage en Java de HTML Tidy, un célèbre outil de validation des pages HTML et autres syntaxes proches (XHTML).

Le projet JTidy semble endormi, la dernière version date de 01/08/2001 et l’activité du site du projet (forum) est assez faible. La documentation manque. Malgré certaines inquiétudes le projet semble suffisant pour ajouter à mes tests unitaires côtés web une méthode assez grossière de contrôle validation du code HTML.

Donc voici le code que j’ai écrit dans le cadre de htmlunit fortement inspiré d’un exemple trouvé dans un blog :

private void checkWithJTidy(HtmlPage htmlPage) {
  //obtenir la page html sous forme tableau de byte
  String input=new String(htmlPage.getWebResponse().getResponseBody());
  
  //flux d'entree
  ByteArrayInputStream bais=new ByteArrayInputStream(input.getBytes());
  //flux de sortie
  ByteArrayOutputStream baos=new ByteArrayOutputStream();
  //flux d'erreur, c'est lui qui contient le résultat
  ByteArrayOutputStream baer=new ByteArrayOutputStream();
  	
  Tidy tidy=new Tidy();
  tidy.setXHTML(true);
  tidy.setOnlyErrors(true);
  tidy.setShowWarnings(true);
  //se mettre en mode non verbeux
  tidy.setQuiet(true);
  	
  PrintWriter pw=new PrintWriter(baer,true);
  tidy.setErrout(pw);
  tidy.parse(bais,baos);
  
  //assertion le flux baer doit être vide
  assertEquals(baer.toString(),baer.toString(),"");
}

Evolution du web mobile

août 7, 2007

La sortie de iPhone a fait beaucoup de bruit et pourrait marquer un tournant du web mobile. Ce téléphone portable est fourni avec le navigateur web Safari et peut en principe naviguer sur les sites « classiques ». La question qui se pose est de savoir si le web mobile est déjà mort. Selon les spécialistes du domaine c’est non. La distinction entre internautes et « mobinautes » va continuer. En effet les terminaux mobiles sont plus contraints que les terminaux classiques et nécessitent des sites adaptés.

Il existe déjà des versions pour iPhone des grands sites comme dailymotion et Google. Pour avoir une idée de l’intérêt de versions de site sans posséder un terminal adapté on peut toujour utiliser l’émulateur d’opéramini ce qui donne les liens directs : http://www.operamini.com/demo/?url=iphone.dailymotion.com/fr et …google.fr….