• À propos
  • About
  • ProxiAD

Proxiad vous parle d'IT

Proxiad vous parle d'IT

Tag Archives: selenium

DevoxxFR 2012 : du nouveau sur les tests

09 Wednesday May 2012

Posted by proxiad in Java, news, Test

≈ 1 Comment

Tags

devoxx, devoxxfr, DSL, gatling, jasmine, Java, javascript, selenium, testng, tests

Dans mon billet précédent, je relatais les sessions de ce DevoxxFR qui m’ont le plus marqué par leur originalité. Je vais maintenant revenir sur les quelques sessions qui concernaient les outils de tests.
Le dernier article de cette série traitera des sessions liées à Java et à son écosystème.

Selenium 2, Selenium Grid et TestNG par Mathilde Lemee (@MathildeLemee)
Mathilde nous présente l’intérêt de Selenium2 pour automatiser les tests IHM. Elle déconseille l’utilisation de Selenium IDE, mais encourage à écrire directement les scénarios en Java, la syntaxe étant relativement simple. Après une présentation des avantages de TestNG comparé à Junit (groupes de tests, dépendances de tests, listeners, tests paramétrés), Mathilde met le doigt sur le point noir des tests sous Selenium : la lenteur d’exécution.
Une solution pour pallier à ce problème est de mettre en place Selenium Grid. Cet outil permet de lancer les tests en parallèle, pourquoi pas sur des VM différentes, avec des OS et browser différents voir même sur le cloud avec Azamon EC2 par exemple.
Une présentation de 30 minutes rondement menée, le tiercé Selenium 2, Test NG et Selenium grid semble pertinent pour maintenir une suite de tests d’intégration opérationnelle.

Réaliser des tests de charges avec Gatling
Cette session est animée par Stéphane Landelle (@slandelle) et Romain Sertelon (@BluePyth) principaux acteurs du projet Gatling.
Gatling est un outil de tests de charge nouvelle génération qui veut rompre avec le modèle classique 1 user = 1 thread. Open source, basé sur Scala, Akka, Netty, l’outil dispose d’un DSL Scala, qui semble accessible avec un peu de pratique. Cerise sur le gâteau, les rapports générés sont visuellement plutôt sympas.
L’outil est encore jeune, mais mérite qu’on y prête attention.

FluentLenium, une autre façon de faire Selenium par Mathilde Lemee (@MathildeLemee)
FluentLenium, est un framework au dessus de Selenium. Il propose un DSL fluide qui augmente la productivité dans l’écriture de tests d’intégration basé sur Selenium. Il permet également la mise en œuvre simple du pattern Page Object Pattern gage d’une meilleure maintenabilité des suites de tests. Il s’intègre très bien avec les bibliothèques d’assertion comme JUnit assertion, Hamcrest ou encore Fest Assert.

Chouchoutez votre code javascript par Romain Linsolas (@romaintaz)
Romain nous montre que faire des tests en javascript, les automatiser et analyser les code javascript, c’est possible avec les mêmes outils que dans l’écosystème Java, à savoir Maven, Sonar, Jenkins. Sur la base du code de la librairie underscore.js, Romain met en place un certain nombre de tests grâce à la librairie orienté BDD (Behavior Driven Development) Jasmine. L’analyse de code et la couverture se font via Sonar ainsi que la librairie js-test-driver.
Encore une très bonne présentation, avec une vraie démo qui fonctionne et un environnement dans lequel le développeur Java se sent comme chez lui.

Advertisements

Vous devriez vraiment tester vos IHM web. Avec quoi? Selenium!

21 Wednesday Oct 2009

Posted by proxiad in Java, Qualité, Test

≈ Leave a comment

Tags

Qualité, selenium, Test, Web

Les tests unitaires classiques sont utilisés pour tester une partie du code d’une application, dans un environnement d’exécution bien maîtrisé. Même si les tests de ce genre sont nécessaires, et que leurs bénéfices ne sont plus à démontrer, il est également important de pouvoir réaliser de véritables tests fonctionnels d’une application web, en condition réelle, c’est à dire déployée sur un serveur d’application et en la testant depuis un navigateur. Selenium est un des outils les plus utilisés pour réaliser ce genre de tests. Après une présentation rapide de cet outil, cet article a pour but de vous exposer mon retour d’expérience sur son utilisation au quotidien.

Selenium est en fait un ensemble d’outils, dont les plus importants sont :

  • Selenium IDE : plugin pour Firefox qui permet d’enregistrer et de rejouer des commandes utilisateur sur une application web – ouverture d’une URL, click sur un bouton, entrée d’une valeur dans un champ, etc. Ces commandes peuvent être exportées sous la forme de tests unitaires dans différents langages (HTML, Java, C#, etc.)
  • Selenium Core : bibliothèque JavaScript, compatible avec un grand nombre de navigateurs, utilisée pour lancer les commandes utilisateur sur l’application web. Cette bibliothèque peut être utilisée directement pour lancer les tests Selenium codés en HTML.
  • Selenium Remote Control : application serveur qui permet l’exécution des tests unitaires Selenium codés en Java, .Net, Perl, PHP, Python ou Ruby et se reposant sur une bibliothèque cliente.

Le schéma suivant présente l’architecture de fonctionnement du Selenium Remote Control :
Architecture de fonctionnement Selenium Remote Control
Voici un exemple de test Selenium codé en Java/jUnit, qui reproduit une recherche sur Google de “blog proxiad” et qui vérifie que le premier résultat retourné est bien le site sur lequel vous surfez actuellement :

public class BlogProxiadTest extends SeleneseTestCase {
    public void setUp() throws Exception {
        setUp("http://www.google.fr/", "*iexplore");
    }
    public void testRechercheGoogle() throws Exception {
        selenium.open("/"); // appel de la page d'accueil de Google
        selenium.waitForPageToLoad("30000"); // attente du chargement complet de la page
        selenium.type("q", "blog proxiad"); // critère de recherche
        selenium.click("btnG"); // click sur le bouton "Recherche Google"
        selenium.waitForPageToLoad("30000");
        assertEquals("ProxiAD vous parle d'IT", selenium.getText("//div[@id='res']/div/ol/li[1]/h3/a")); // titre de la page du 1er résultat
        assertEquals("blog.proxiad.com/ -", selenium.getText("//div[@id='res']/div/ol/li[1]/div/cite")); // URL de la page du 1er résultat
        selenium.click("link=ProxiAD vous parle d'IT"); // click sur le lien
        selenium.waitForPageToLoad("30000");
        verifyTrue(selenium.isTextPresent("EDITO")); // l'édito doit être présent sur la page d'accueil
    }
}

Le code de base du test a été généré par Selenium IDE, puis modifié de la façon suivante :

  • ajout de commentaires
  • ajout d’une temporisation après le clic sur le bouton de recherche : la commande waitForPageToLoad n’est pas toujours générée par Selenium IDE
  • retouche des expressions XPath, de façon à correctement référencer la première ligne de résultat de la recherche, car la pub Google, lorsqu’elle apparaît dans la marge droite, rend caduc les expressions XPath générées par Selenium IDE

En général, le code généré par Selenium IDE n’est pas utilisé tel quel. On doit parfois exécuter des traitements avant et après chaque test : affichage de la page d’accueil de l’application, clic sur un bouton “Déconnexion”, etc. On a parfois besoin également d’accéder à la base de données pour récupérer certaines informations ou faire des assertions, et il convient de les réaliser au sein du test Selenium, au moment où l’on en a besoin, et en prenant soin de ne pas être dans un contexte transactionnel, sans quoi le niveau d’isolation empêcherait de voir les données modifiées par l’application.

La mise en œuvre de Selenium sur une application web nécessite très souvent des adaptations ou des petites corrections de l’application, mais on peut voir ces modifications comme des améliorations de l’existant. Par exemple, à moins de pouvoir s’en passer, il faut que l’application testée puisse fonctionner sous Firefox, puisque Selenium IDE ne fonctionne que sous ce navigateur. Cela nécessite parfois de réécrire certains codes JavaScript, qui peuvent présenter une incompatibilité, mais ces corrections sont souvent mineures.

Autre exemple : la localisation d’un élément sur une page de l’application n’est parfois possible qu’avec une expression XPath référençant la position exacte d’un élément HTML, du type /html/body/table/tbody/tr/td/div/div[2]/ul/li/ul/li[8]/a. A chaque modification de la page testée, ce genre d’expression XPath n’est plus forcément valide. C’est pour cela qu’il faut modifier les pages testées pour que les recherches dans l’arbre DOM soient facilitées : ajout d’identifiants sur les éléments remarquables de la page, utilisation de la balise alt pour identifier les images ou certains liens, etc.

Selenium est très complet et peut s’adapter à la majorité des applications web, y compris celles qui utilisent des frames, des fenêtres pop-up ou même de l’AJAX, mais l’expérience montre qu’il faut souvent retoucher le code généré pour que le test fonctionne correctement : ajout de commandes waitForPageToLoad, selectFrame, selectWindow ou, pour les pages utilisant AJAX, les commandes waitForXxx ou waitForNotXxx. Il y a cependant certains cas particuliers qui ne sont pas gérés, et qui peuvent bloquer complètement le test, comme les fenêtres d’alertes provenant du navigateur, les alertes JavaScripts générées depuis l’évènement onLoad de la page, ou encore les uploads de fichiers qui ne sont pas supportés, mais des solutions de contournement sont possibles.

Enfin, il est possible d’intégrer l’exécution des tests Selenium dans un processus d’intégration continue, pourvu que l’on arrive à automatiser toutes les étapes nécessaires : construction des livrables applicatifs, déploiement de ces livrables sur le serveur d’application, lancement des tests Selenium contre l’application déployée. En pratique, de nombreux outils sont capables de faire cela (par exemple Maven avec le plugin Selenium pour la gestion du Selenium Remote Control, et le plugin Cargo pour le déploiement sur le serveur d’application). Mais on s’aperçoit assez vite que l’ensemble de ce processus est très lourd, et que les tests Selenium s’exécutent très lentement par rapport à de véritables tests unitaires du code de l’application. C’est pour cela qu’en général on se limite à une exécution par jour de ces tests. Pour information, il existe plusieurs moyens de paralléliser l’exécution des tests Selenium, et de gagner en rapidité d’exécution : Selenium Grid pour la multiplication des instances de Selenium Remote Control, exécution multi-threadée des tests Selenium, mais il faut dimensionner l’infrastructure de test en conséquence.

Dans un prochain article, je vous présenterai Tellurium, un fork de Selenium qui ajoute de nouvelles fonctionnalités et qui semble prometteur.

Advertisements

Subscribe

  • Entries (RSS)
  • Comments (RSS)

Archives

  • February 2013
  • January 2013
  • June 2012
  • May 2012
  • April 2012
  • January 2012
  • December 2011
  • November 2011
  • September 2011
  • June 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • September 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • November 2009
  • October 2009
  • September 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009

Categories

  • Agilité
  • Build
  • Cloud
  • DSL
  • EAI
  • EDITO
  • Industrialisation
    • Provisioning
  • Java
    • Eclipse RCP
    • Java EE
    • Spring
  • Microsoft
    • .Net
  • Model Driven
  • news
  • Non classé
  • Performances
  • PHP
  • populaire
  • Portail
  • Productivité
  • Qualité
  • Sécurité
  • SOA
  • Test

Meta

  • Register
  • Log in

Create a free website or blog at WordPress.com.

Cancel