Selenium RC (Remote Control)

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.

Publicités

3 Réponses to “Selenium RC (Remote Control)”

  1. ly Says:

    J’ai vraiment aimé votre article et j’aimerai vous poser ds questions car j’utilise selenium et votre connaissance me permettra sans doute de progresser sur les test.

  2. petitteckel Says:

    Vous pouvez poser vos questions.

  3. Alex Corben Says:

    Article très sympa. Il faut que je fouille dans tout le Blog, visiblement beaucoup de choses à apprendre.
    Merci de toutes ces infos et encouragements pour la suite.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s


%d blogueurs aiment cette page :