<p>
Pour la première rencontre du ParisJUG, Zouheir Cadi a présenté à un auditoire de bonne humeur le produit open-source Selenium.
Voici un résumé de ce que l'on a pu en retenir.
Selenium est à placer dans la catégorie des "web testing tools".
Il est décomposé en plusieurs modules :
- Selenium Core[SC] : c'est un composant (HTML + Javascript) côté serveur dont le but est d'exécuter des jeux de tests d'interface sur une application web à tester sur le même serveur.
Plusieurs instructions de test formatées dans un tableau HTML forment un jeu de test exécutable. Exemple :- ouvrir l'url http://localhost/monApplication/
- cliquer sur le lien "contact"
- vérifier que la page contient un bouton "envoyer"
Ces tests sont écrits dans la syntaxe Selenese[SE]. L'inconvénient rappelé par l'intervenant est que cela nécessite de déployer ce Framework de test sur le serveur qui héberge l'application web à tester. - Selenium IDE[SI] : c'est un plug-in firefox qui permet de charger et d'exécuter des jeux de test et de capturer une séquence utilisateur en "live" tout en offrant la possiblité d'éditer les instructions en intercalant des assertions de vérification. De nombreux formats d'export sont supportés, citons le natif format HTML (avec des tableaux) ou la classe java (dépendante de JUnit).
Zouheir nous a détaillé la forme d'une instruction qui peut être une Action agissant sur un élément du dom de la page HTML repéré à l'aide d'un Accessor. L'autre type d'instruction est l'Assertion qui permet de vérifier un postulat dans une page. - Selenium Remote-control[SR] : c'est un serveur java (un jar ! ) qui embarque Selenium Core et qui permet d'exécuter les jeux de test dans un langage cible plus expressif que Selenese (Java, Ruby, pyton...) en lançant un navigateur préalablement configuré avec le proxy de Selenium Remote-control. Le navigateur sera alors "contrôlé" (d'où le nom du composant) en recevant les requêtes HTTP de Sélenium Remote-control.
Au delà de cette présentation en règle du framework, la valeur ajoutée incontestable de cette session fut l'interactivité avec l'auditoire et la phase de démonstration : Selenium IDE, Selenium Remote-control, l'intégration de Selenium à Maven[MV], le passage des tests Selenium dans Continuum[CO].
Cette partie concrète a soulevé de nombreuses questions et permit de toucher à l'intégration continue.
- Si on utilise Selenium IDE, télécharger aussi l'extension XPather[XP] qui permet de faciliter l'édition des Accessors de type XPath.
- Attention, l'export en classe Java Junit d'un test Selenium IDE contraint l'arbre d'héritage de cette classe à l'intérieur de l'API Selenium (com.thoughtworks.selenium.SeleneseTestCase)
- Attention, toutes les dépendances Selenium Remote-control ne sont pas hébergées par le repository central de maven, il faut configurer un repository tiers (http://maven.openqa.org)
- Les instructions Selenese sont portées en java pour l'écriture des tests JUnit (à l'exception des assertions - déjà présentes dans JUnit)
- Faire fonctionner Selenium Remote-control avec maven permet de l'intégrer à bas coût dans le cycle d'intégration continue dans un serveur Continuum par exemple (démo brillante)
Les débats ont rapidement migré vers la testabilité en général : Comment bien tester une application ? Jusqu'où aller dans la précision du cas de test ? Qui doit tester l'IHM ?
Zouheir a conclu sa présentation d'outil en rappelant que Selenium n'était pas la solution miracle pour des sites "compliqués" (ajax) en s'adressant dans ce cas à un utilisateur avancé voir un développeur. Mais cette solution reste très efficace pour tester les interfaces des sites "simples".
Pour terminer, les réflexions suivantes sont issues de quelques discutions avec les participants.
Pourquoi mettre en place des tests unitaires IHM de non régression ?
- parce que notre client nous fait part de régressions
- parce que l'automatisation des tests répétitifs en fin d'itération permet de gagner du temps
- Un long test Selenium est compliqué à maintenir
- Ecrire des tests très ciblés, de faible granularité, se concentrant sur un seul enchaînement d'écran
avantages : de proche en proche la suite de petits tests on teste le cheminement global dans l'application, la maintenabilité du test est augmentée - Adopter un pragmatisme continu en se posant aussi souvent que possible la question : jeter le test et le recommencer ou maintenir le script ?
- Comment mesurer les gains des tests IHM ? Le nombre de régressions, temps pour la validation usine (0 avec l'intégration continue ?), temps pour faire une recette
- [Con$eil] Si on démontre qu'on fait gagner du temps aux testeurs/recetteurs de la maîtrise d'ouvrage au fil des itérations, se faire financer l'écriture et la maintenance des tests au même titre que n'importe quelle fonctionnalité.
- Tests et données : éviter de tester l'interface contre des données métier affichées à l'écran - d'autres frameworks sont plus efficaces pour les tests fonctionnels (FIT[FI], FITNesse[FS]
Selenium est un outil **efficace**. Il apporte une valeur ajoutée en termes de productivité sur les tests IHM.
Cette présentation a permis aux "Java Users" présents d'avoir un aperçu exhaustif des fonctionnalités de Selenium pour prendre les bonnes décisions dans leurs stratégie de test appliquée à leurs projets.
Avec cette présentation, le Paris JUG a vraiment transformé sa première rencontre en un moment utile et rempli de bonne humeur.
Sinon, le selenium est un bon anti-oxidant prévenant le cancer, par contre, à forte dose, il peut être toxique. Ne pas en abuser.
[SC] : Selenium Core
[SE] : Selenese
[SI] : Selenium IDE
[SR] : Selenium Core
[MV] : Selenium + Maven = selenium-maven-plugin
[CO] : Continous web testing with Selenium, Maven and Continuum
[XP] : XPather
[FI] : FIT
[FS] : FITNesse