Archive for the ‘Tests’ Category

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.

Les outils de test commerciaux iMacros et eValid

octobre 15, 2008

Concernant les tests des applications web, je me suis posé la question s’il est possible de tester des applets. Cette problématique pourrait être généralisée aux autres technologies comme Flash Silverlight. Les outils libres ne semblent pas répondre à cette question. Je me suis tourné vers des outils commerciaux, iMacros et eValid.

IMacros existe sous forme de plugin pour navigateur web en freeware, également pour une utilisation commerciale. Ce plugin existe pour les navigateurs Firefox et Internet Explorer. Les tests sont écrits avec un langage de script spécifique. Il existe un enregistreur. Le site d’Iopus déclare que iMacros supporte les technologies Flash, Flex, Java, Silverlight. Dans la pratique le freeware ne semble pas fonctionner correctement, et le principe semble de repérer au pixel près la position du curseur. Est-ce réellement portable.

Le second outil qui peut répondre à ce problème est eValid. Je n’ai pas pu réellement le tester.

Webdriver nouvelle version (524)

septembre 25, 2008

La version de Webdriver 524 est sortie le 18/09/2008. Pour rappel, Webdriver est un outils de test des applications web se basant sur le langage Java. Il s’agit toujours d’une version « alpha ». Cependant ses principes sont intéressants. Ce projet mérite donc d’être suivi attentivement. En plus, ce projet est soutenu par Google, devenue une sociétés informatiques parmi les plus puissantes.

Il s’agit en fait d’une interface simple. C’est à dire une API assez simple avec très peu de classes. Plusieurs implémentations existent, il est possible d’écrire de nouvelle implémentation. En fait quatre implémentations sont proposées.

  • Safari (mais pour Mac OS uniquement)
  • Firefox
  • htmlUnit (basé sur la version 2.2 d’HtmlUnit)
  • jobbie (Internet Explorer)

Dans les versions précédentes sous Vista, seules les implémentations Firefox et HtmlUnit fonctionnaient correctement. Dans cette nouvelle version, la version pour IE fonctionne. Voici quelques actions à effectuer après l’installation. Pour Firefox, il faut définir un profil webDriver. Utilisez en mode commande « firefox -p ». Pour la version Internet Explorer sous Vista, il faut ajouter les domaines utilisés lors des tests dans les sites de confiance. Avec Internet Explorer 7, utiliser le menu Outils\Options Internet, aller à l’onglet Sécurité et changer la liste des sites de confiance.

Au final, j’ai commencé une méthode d’évaluation des outils de test des applications web. Il s’agit d’une série de tests simples à écrire pour évaluer une application écrite avec Strust version 1.4. Pour l’instant le nombre de tests est de 4, mais je compte l’augmenter progressivement. Au final, les versions HtmlUnit et Firefox réussissent l’évaluation. Par contre, la version Internet Explorer échoue sur un test.

Implémentation Fonctionne sous Visa Evaluation
Safari Non (Mac OS X uniquement) N/A
Firefox Oui 4/4
HtmlUnit Oui 4/4
Jobbie (Internet Explorer) Oui 3/4

Comparaison des différents navigateurs Web basée sur les tests Acid

septembre 20, 2008

Une piste de comparaison des navigateurs web est le respect des standards Web. Plusieurs tests ont été mis en place pour montrer le respect ou non par les navigateurs web des standard du web. Ceci évite une « balkanisation » du web. Le test Acid1 été mis en place en 1998 par Tod Fahrner et ne concerne que les CSS. Il n’a qu’un intérêt historique. Les deux suivants Acid2 et Acid3 dépendent du WASP (Web Standards Project). Le test Acid2 date de 2005. Il ne concerne que les CSS1 et CSS2. Son résultat est purement visuel. Le dernier Acid3 concerne un spectre plus large de technologies DOM level2, JavaScript, CSS3, SVG… Il est très récents 2008. Le résultat est une note sur 100. Il s’agit de 100 tests de base. Il est possible de voir les tests ayant échoué. Enfin, il existe un site qui regroupe l’ensemble des test acid.

La liste suivante se compose des principaux navigateurs actifs disponibles pour Windows, en dehors des surcouches pour IE (comme CrazyBrowser et Maxthon). Les navigateurs abandonnés comme Netscape n’y sont pas présents. Pour l’instant cette liste compte 8 membres.

La comparaison a été faite avec les dernières versions stables des navigateurs sous Windows Vista. Il est remarquable que les deux grands sont loin d’être les premiers. Firefox passe le test Acid2 depuis sa version 3. IE est toujours bon dernier. Les équipes de Microsoft n’ont jamais officiellement mis ces tests Acid en priorité. Les navigateurs basé sur le moteur de rendu de Firefox 2, K Meleon, Flock et SeaMonkey obtiennent en gros le même résultat. Enfin, aucun navigateur obtient 100 au test Acid3.

Voici les résultats détaillés :

Navigateur Version Test acid 2 Test acid 3
Opera 9.52 Oui 84/100
Google Chrome 0.2.149.29 Oui 78/100
Safari pour Windows 3.1.2 Oui 75/100
Firefox3 3.01 Oui 71/100
K Meleon 1.5 Non 53/100
Flock 1.2.5 Non 53/100
SeaMonkey 1.1.11 Non 52/100
IE 7 Non 12/100

Le test de performance JavaScript SunSpider

septembre 18, 2008

SunSpider est un test de performance du moteur de JavaScript. Ce test a été écrit par l’équipe de WebKit le moteur de rendu HTML présent dans les navigateurs sous Mac OS, comme Safari. Ce benchmark exécute 5 fois une série de tests et fournit une moyenne.

Le JavaScript est assez important pour les utilisateurs des applications web. En effet, le type de code est exécuté sur le client et non le serveur. L’importance de ce langage s’est accrue avec le Web 2.0. Cependant, la performance du moteur de JavaScript n’est qu’un élément dans le performance globale du navigateur web. Cela ne présume pas de la performance globale du navigateur.

Les résultats suivants ont été obtenus sur Windows Vista avec les navigateurs actifs, les plus courants dans leurs dernières versions stables. Google Chrome avec son tout nouveau moteur V8 obtient un résultat remarquable. Par contre celui d’Internet Explorer 7 est médiocre, en effet le moteur de JavaScript de ce navigateur est de conception ancienne et devrait être remplacé dans la version 8.

Navigateur Version Résultat
Google Chrome 0.2.149.29 3 301 ms
Firefox 3.01 5 558 ms
Safari 3.1.2 7 019 ms
Opera 9.52 7 931
K Melon 1.5 15 321 ms
SeaMonkey 1.1.11 21 422 ms
Flock 1.2.5 23 214 ms
IE 7 58 033 ms

L’outil de test des applications web WebDriver

août 12, 2008

WebDriver est un nouvel outil de test des applications web. Il s’agit d’un projet faisant partie du site code.google.com, qui regroupe des projets développés par les employés de cette entreprise. le site de WebDriver est http://code.google.com/p/webdriver/. Une présentation vidéo de cet outil lors du GTAC 2007 (Google’s Test Automation Conference) est disponible sur le site YouTube .

Il s’agit d’une API Java permettant de simuler ou de piloter un navigateur web. L’équipe à l’origine de WebDriver parle de navigateur idéalisé. WebDriver est similaire aux outils comme htmlUnit, HttpUnit, JWebUnit, ou Selenium Remote Control. Il fait partie des outils de test des applications web.

L’API WebDriver est de haut niveau, comme celle de JWebUnit par opposition aux API de bas niveau HtmlUnit et HttpUnit. Le but est de simuler un utilisateur manipulant une interface web, pas analyser ou manipuler les requêtes web. Comme JWebUnit, WebDriver utilise des API de plus bas niveau dans la pratique uniquement HtmlUnit. Il reste cependant ouvert à utilisation d’autres API comme Selenium RC. JWebUnit dans sa version 2 devrait permettre l’utilisation en plus d’HtmlUnit de Selenium RC, HttpUnit et Jacobie.

WebDriver est en fait une interface qui peut utiliser des implémentations différentes. Ces implémentations sont soit des API de bas niveau qui simulent des navigateurs web comme HtmlUnit, soit des outils pilotant des navigateurs web. Il s’agit de Firefox, et Internet Explorer pour Windows, Safara pour Mac OS X. Une implémentation utilisant un navigateur web permet d’avoir un support natif du Javascript et de suivre visuellement les tests. Donc, il est donc possible de vérifier leur fonctionnement et de les faire évoluer. Par contre, cette méthode est plus lente que des tests utilisant un simulation d’un navigateur web. Un simulateur est plus rapide mais propose un support imparfait du javascript.

Contrairement aux outils concurrents, l’API de WebDriver est très simple. L’API tourne autour de deux classes WebDriver (le navigateur) et WebElement (un élément dans page courante). Les API de HttpUnit et HtmlUnit sont à côté complexes. Le choix de l’implémentation de la classe WebDriver définit le type d’implémentation utilisé (HtmlUnit, Firefox, IE ou Safari).

Dans la pratique, cet outil est disponible en version « alpha ». La version du 31/07/2008 que j’ai évaluée n’est utilisable uniquement avec les implémentations HtmlUnit et Firefox. Il suffit de changer l’instruction d’initialisation de la classe WebDriver pour choisir l’implémentation Firefox ou HtmlUnit.

Voici des exemples de code:

WebDriver driver;
driver = new FirefoxDriver(); //piloter Firefox
driver = new HtmlDriver(); //utiliser HtmlUnit

Il faut mettre de temps à autre des « pause » pour pouvoir visualiser le résultat.

Thread.sleep(tempo); //tempo est grand pour Firefox mettre 1 pour htmlUnit.

WebDriver souffre de limitations : il est instable et sa documentation est partielle. Je ne le conseille pas pour une utilisation dans un projet important. Les outils matures dans le domaine des tests des applications web sont plutôt HtmlUnit et JWebUnit.

Outils de test d’application web en Ruby

juin 3, 2008

J’ai repris récemment l’ensemble des outils de test d’application web utilisant le langage Ruby. Au départ, je cherchais des outils pilotant des navigateurs web. La solution la plus prometteuse était watir. L’environnement que j’utilise maintenant est Windows Vista avec le navigateur Internet Explorer 7. Les autres navigateurs que j’utilise ici sont Safari, SeaMonkey, Opera, Firefox et Flock.

Pour commencer, il faut installer le langage Ruby. Pour Windows, il existe la version 1.8.6. L’installation ne pose pas de problème. Double click sur un exécutable. Watir est une librairie Ruby qui pilote Internet Explorer. Associé avec la librairie de test du langage Ruby (Test::Unit), elle permet de tester les application web. Watir peut cependant servir à d’autres tâches d’automatisation. Test::Unit est la version pour le langage Ruby du framework xUnit. A titre de comparaison, la version pour le langage Java est JUnit. Test::Unit est installé par défaut avec le langage Ruby. La version de Watir est la 1.5.4 datant du 08/04/2008.

L’installation de Watir ne pose pas de problème, il suffit d’utiliser les commandes « gem ». L’archive est sous le forme d’un fichier gem.

gem install –local watir

Watir fonctionnait correctement sur des anciennes versions de Windows comme XP. Mais sur Windows Vista, cette librairie semble inutilisable. En effet, le navigateur démarre, même si la gestion des onglets est assez étrange. Par contre, il n’est pas possible d’aller plus loin comme remplir des champs ou cliquer sur des bouton. Cela semble provenir d’un problème de sécurité au niveau du système.

Il existe des portage de watir en java avec watij et en C# avec WatiN. Je n’ai testé que Watij qui pose exactement le même problème que Watir sous Windows Vista.

Il existe également des librairies en Ruby pour piloter les autres navigateurs. Safariwatir permet de piloter le navigateur Safari sous Mac OS uniquement (pas sous Windows). Il n’a donc pas beaucoup d’intérêt dans mes environnements techniques. Firewatir concerne le navigateur. Il fonctionne correctement sous Windows Vista (enfin !). La dernière version est la 1.1.1 du 08/04/2008. L’illustration avec le google test peut être la suivante :


require "firewatir"
test_site = "http://www.google.com"
ff = FireWatir::Firefox.new
ff.goto test_site
ff.text_field(:name, "q").set "pickaxe" # "q" is the name of the search field
ff.button(:name, "btnG").click # "btnG" is the name of the Search button

La seconde piste pour utiliser le langage Ruby pour les tests des applications web est d’utiliser la suite d’outils Selenium. Selenium remote control permet de faire des tests en pilotant des navigateurs web. Il n’est pas limité à un navigateur. Il n’est pas limité au seul langage Ruby. Il est possible par exemple d’utiliser le langage Java. Contrairement à Watir, Selenium est orienté exclusivement outil de test.

L’installation de la librairie Ruby est assez simple. L’archive Selenium remote control contient un serveur dans le dossier selenium-server. Le lancement de ce serveur se fait en double clickant sur l’archive selenium-server.jar ou par la commande java -jar selenium-server.jar. Le serveur utilise par défaut le port 4444.

Il est possible d’utiliser Selenium remote control avec 6 langages de programmation différents : dotnet, java, perl, php, python et Ruby. Pour utiliser le langage Ruby, il faut placer le fichier selenium.rb du dossier selenium-ruby-client-driver-* dans le dossier \lib\ruby\1.8 de l’installation du langage Ruby.

Selenium remote control permet de faire des tests en ruby avec de nombreux navigateurs. Il faut mettre au préalable l’exécutable correspondant au navigateur dans le path de Windows. Sous Windows Vista, les navigateurs IE, Firefox et Opera fonctionnent. Cela ne fonctionne pas pour les navigateurs Safari, Seamonkey et Flock. Voici un exemple du « google test » dans le cas du navigateur Firefox.


require "Selenium"
browser = Selenium::SeleniumDriver.new("localhost",4444,"*firefox","http://www.google.fr");
browser.start;
browser.open("http://www.google.fr");
puts browser.get_title();

Le troisième paramètre de l’operateur new définit le type de navigateur. « iexplore » pour IE, « *safari » pour Safari et « *opera » pour Opera. Si le navigateur n’est pas dans la liste des navigateurs par défaut, il est possible d’utiliser « *custom » suivi du chemin complet de l’exécutable du navigateur.


#browser = Selenium::SeleniumDriver.new("localhost",4444,"*custom E:/program/opera/Opera.exe","http://www.google.fr");

Le plugin Eclipse openQA Selenium IDE

septembre 18, 2007

Je continue sur le sujet des tests en général et celui des applications web en particulier. Je désire un outil de test au niveau interface web orienté utilisateur, simple d’utilisation, accessible aux non développeurs. De préférence, cet outil doit fonctionner directement dans un navigateur web et permettre d’enregistrer les tests à partir d’une navigation sur le site. Tout ceci pour faciliter des tests d’acceptance.

Je me suis orienté sur OpenQA Selenium IDE. QA signifie ici Quality Assurance ou en français Assurance Qualité. Rien ne vous empêche naturellement de regarder les autres outils de la famille Selenium. Dans un premier temps, j’y ai renoncé à approfondir les autres pour me contenter de Selenium IDE. La version actuelle est la 0.8.7 datant du 21/03/2007. Il s’agit d’un outil de test s’exécutant directement dans le navigateur web, sous forme d’extension (plugin) pour Firefox. Pour enregistrer, le test il suffit d’appuyer sur le bouton d’enregistrement et d’exécuter le test qu’on désire rejouer plus tard.

Il faut avouer que il est parfois nécessaire de modifier le résultat de l’enregistrement. Heureusement, la syntaxe des actions est relativement simple . Il s’agit un triplet commande, cible valeur. Un exemple simple est le renseignement d’un champ dans un formulaire (type, nom du champ, valeur). La partie valeur est parfois inutilisée comme par exemple lors du click sur un bouton. Certaines commandes se terminent par wait pour signifier d’attendre la réponse du serveur, il existe un timeout par défaut. Le format d’enregistrement des tests est en HTML. C’est un peu surprenant mais tout à fait utilisable, les actions sont placées dans un tableau HTML.

Un exemple de code utile est de générer du texte aléatoire, par exemple pour enregistrer un référence unique. Il suffit d’ajouter un peu de javascript.

<tr>
<td>store</td>
<td>javascript{'subject' + (new Date()).getTime()}</td>
<td>subject</td>
</tr>
<tr>
<td>type</td>
<td>subject</td>
<td>${subject}</td>
</tr>
<tr>
<td>assertTextPresent</td>
<td></td>
<td>${subject}</td>
</tr>

Il existe plusieurs commandes d’assertion assertTitle assertTextPresent… Mais une particularité de cet outil est d’avoir des commandes commençant par verify (verifyTitle, verifyTextPresent….). Les commandes « assert » arrête le test si la condition n’est pas vérifiée. Verify continue le test. Ces commandes Verify sont contraires aux principes des tests unitaires. Si vous voulez vérifier deux choses et ne pas s’arrêter au premier test, il faudrait écrire deux méthodes de test différentes. Mais ici, nous sommes bien en test d’acceptance, donc il est envisageable d’avoir ce genre de commande pour collecter le maximum d’information. Dernier point les commandes sont de haut niveau orientées utilisateur, il n’est pas possible d’étendre ce jeux de commandes.

Ce projet est finalement très facile à pendre en main. Je reproche un peu le manque de documentation, il existe bien une FAQ un wiki mais il n’y a pas grand chose dedans. Il est possible après de faire des « testSuite » c’est à dire regrouper les différents scénarios de tests dans un seul fichier qui appelle les autres fichiers, nommons le testsuite.html.

<table>
<tr>
<td>Test suite for the whole application</td>
</tr>
<tr>
<td><a target="testFrame" href="test1.html">Test1</a></td>
</tr>
<tr>
<td><a target="testFrame" href="test2.html">Test2</a></td>
</tr>
</table>

Pour exécuter la suite de test, il faut appeler l’url chrome://selenium-ide/content/selenium/TestRunner.html?
baseURL=http://localhost&test=file:///dir/testsuite.html&auto=true. A vous d’adapter les bons paramètres. Ce principe des tests suite est inspiré directement de JUnit. Il est cependant pas possible de combiner ces « tests suites » pour former d’autres « tests suites » suivant le modèle de JUnit.

Enfin, j’ai trouvé un pdf de présentation en français.

Le logiciel commercial Jira de gestion des anomalies

septembre 16, 2007

Attention, pour une fois je ne vais pas parler d’un logiciel libre, mais d’un logiciel commercial. Jira est un logiciel de gestion des anomalies et des faits techniques, ou plus simplement suivi de bug. On trouve parfois aussi l’anglicisme bug tracking.

Il existe également des alternatives parmi les logiciels libre dont le célèbre bugzilla. Je n’ai pas encore suffisamment de recul pour pouvoir juger ces différents logiciel. Simplement Jira se veut en avance sur ses concurrents commerciaux ou libres.

Le logiciel Jira est commercialisé par la société Australienne Atlassian fondée en 2002. Je n’ai pas trouvé de chiffres concernant le nombre d’employés ou le chiffre d’affaire. Les autres solutions de cette société sont confluence (wiki et blog d’entreprise), Crowd (solution de SSO ou Single Sign On) et Bamboo. Tous les logiciels de Atlassian sont gratuits pour les projets open source, donc Jira est assez courant sur Internet. il est possible d’avoir une licence gratuite pour une utilisation personnelle de certains logiciels ou d’avoir une version d’évaluation.

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);
	}
}