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.
