JS Bournival

Ça a commencé par une application que je dois produire pour mon client, une institution banquaire. Au coeur de l’application sied un gros formulaire dont plusieurs options résultent en plusieurs comportement. Je me suis alors tout de suite insurgé: «ah tab***k, j’ai pas envie de me taper ce formulaire à chaque test que je devrai faire».

Permier réflexe: me trouver un plugin firefox (mon client est normalisé sur IE6) qui va me remplir mon formulaire avec plusieurs jeux de données. Puis, j’ai extrapolé en me disant que les outils de tests fonctionels feraient parfaiement l’affaire, en plus de valider mes requis au sens large, et pas seulement pour scripter mon contraignant formulaire.

Selenium

Le premier outil que j’ai essayé, Selenium, m’a donné pas mal de fil à retordre. J’ai dû choisir la version qui me convenait le mieux, parce que l’outil vient en 3 saveurs (dont 2 intéressantes, la troisième concerne l’exécution de tests en mode distribué):

Selenium Core: un environnement d’exécution de tests en javascript, qui roule dans le fureteur. Les scripts de tests sont écrits en «selenese» (ou plutôt en selanais), qui consiste en une table HTML à 3 colonnes:

<table>
	<tr>
		<td>open</td>
		<td>http://fr.wikipedia.org/wiki/Jean_Charest</td>
		<td></td>
	</tr>
	<tr>
		<td>verifyTextPresent</td>
		<td>John James Charest</td>
		<td></td>
	</tr>
</table>

Bien que des gens peuvent trouver cela vraiment étrange, Selenium IDE, un plugin Firefox, permet de générer son script tout en cliquant ça et là dans son application web.

Selenium Remote Control: Un peu plus évolué, il permet de démarrer un serveur qui servira de proxy aux requêtes et réponses provenant d’un fureteur littéralement télécommandé. L’ennui avec ce truc, c’est que je suis sur un fureteur normalisé à IE6, et verrouillé (ce qui est ennuyeux parce que Selenium, en démarrant le fureteur va jouer dans paramètres de proxy).

Bref, mes impressions sont plutôt mitigés sur cet outil. D’abord j’ai dû me battre avec la configuration SSL de Selenium, qui n’est pas triviale à mettre en place (en fait je n’ai jamais réussi à la faire fonctionner). En bizounant un peu j’ai réussi à le faire fonctionner chez moi.

Ses atouts sont visiblement le support donné aux tests de javascript qui semble vraiment époustouflant, et aussi le fait de pouvoir écrire ses scripts en plusieurs langages (Python, Ruby, Javascript, «Selenese», et d’autres), mais pas Groovy.

Mais je n’étais pas très heureux. Je voulais quelque chose de plus intuitif, que je pourrais mettre en place rapidement. Je suis alors tombé sur WebTest de Canoo.

Canoo WebTest

WebTest est cet outil, basé sur un environnement d’exécution Ant. Déjà j’étais en terrain connu. Les scripts sont écrits en XML, ou en Groovy. Il s’appuie sur la librairie HTMLUnit pour tester de façon granulaire les éléments des pages web. Finalement, il semble s’accrocher plus facilement à un processus d’intégration continue (ex. Hudson, CruiseControl).

Pour le mettre en place dans son projet, il s’agit simplement de se positionner sous le répertoire racine du projet et de faire une commande:

myproject$> webtest -f $WEBTEST_HOME/webtest.xml wt.createproject webtest

Une fois terminée, cette commande a créé les fichiers nécessaires à l’exécution des tests pour votre application. Reste à écrire les tests, et chacun de ses «steps»:

<webtest name="check that WebTest is Google's tops">
	<invoke url="http://www.google.com/ncr" />
	<verifyTitle text="Google" />
	<setInputField name="q" value="WebTest" />
	<clickButton label="I'm Feeling Lucky" />
	<verifyTitle text="Canoo WebTest"/>
</webtest>

Puis, simplement rouler la commande, et suivre les traces:

myproject$> webtest

Un rapport HTML complet avec statistiques sera projeté dans votre fureteur par défaut une fois l’exécution complété.

Beaucoup plus facile à mettre en place, Canoo WebTest m’a permis d’élaborer plusieurs scénarios en quelques minutes, puis de les commettre sous CVS pour exécution future. Les caractéristiques intéressantes que j’ai retenu sont:

• support Javascript/Ajax
• permet d’externaliser des séquences fréquemment utilisé (ex. s’authentifier, sélectionner un dossier client)
• si un Step n’existe pas pour un cas compliqué, il est possible d’insérer du code Groovy au sein même du XML de votre script
• s’intègre merveilleusement à Grails

l’avantage majeur de Selenium est de tester votre application directement dans les fureteurs que vous devez supporter. WebTest, lui, repose sur une librairie de code compilé. Mais, de façon générale, j’ai de beaucoup préféré travailler avec WebTest, et j’ai bien l’intention de poursuivre.

Voici quelques ressources pour vous permettre de vous faire une idée sur cet outil vraiment exceptionnel.

Canoo WebTest
http://webtest.canoo.com/

Wiki
http://webtest-community.canoo.com/wiki/space/start

Liste courriel
http://lists.canoo.com/mailman/listinfo/webtest

Firefox Recorder, permet de générer un script en navigant le site
https://addons.mozilla.org/fr/firefox/addon/5819

Plugin Maven
http://maven-plugins.sourceforge.net/maven-webtest-plugin/

Plugin Hudson, permet de publier les rapports
http://hudson.gotdns.com/wiki/display/HUDSON/WebTest+Presenter+Plugin

Plugin Grails, s’intégre à la plateforme de développement Grails
http://grails.org/Functional+Testing

Blogosphère
http://mguillem.wordpress.com/2007/10/29/webtest-vs-selenium-webtest-wins-13-5/
http://www.deveshwar.com/softengg/test/CanooWebtestBestPractices
http://www.groovyongrails.com/article/107

Articles
http://www.infoq.com/news/2007/11/canoo-webtest-selenium-testing

Présentations
http://www.grails-exchange.com/files/DierkKoenig%20-%20CanooWebTest.pdf

Vidéos
http://video.google.com/videoplay?docid=-3779950329348771651

JS.