Live Coding and Testing with Javascript, Jean-Laurent de Morlhon
Je commence par la track Agile, en participant à la présentation de Jean-Laurent, développeur indépendant depuis mi-2013. Il est co-fondateur du site Serpodile et co-organisateur du concours Code-Story. Jean-Laurent débute par se présenter :
J’ai 40 ans, je suis programmeur, et non, je n’ai pas râté ma vie 🙂
Le ton est donné. On en reparlera en fin de journée, à la fin de cet article. Restez dans le coin.
Au programme donc, nous allons parler tests. Un programmeur c’est quelqu’un qui écrit du code et qui le teste. Vous avez certainement un titre, peut-être un peu ronflant comme « Lead Senior Architect Head of Development ». Facile de comprendre ce que chaque « titre » veut dire, voici une petite matrice de lecture simple :
- Senior : old
- Manager : expandable
- Architect : can’t code
- Evangelist : can’t ship
Tester c’est tout simplement s’assurer des petits succès de façon incrémental, afin de garantir la qualité de son code, et donc pour s’éviter du debugging ou des tests à posteriori. Il cite le livre « Growing object-oriented software guided by tests » de S.Freeman et N.Pryce, l’une des références pour apprendre à écrire des tests. Comment peut-on mettre en place sérieusement du développement de logiciel piloté par les tests ?
La suite de la présentation et la partie « live coding » permettent de découvrir le test d’une application Web. Les tests automatiques d’un site internet, ou d’une application web, sont en règle générale, les tests les plus fragiles. Il faut donc des outils de tests simples et qui permettent d’effectuer des modifications rapidement.
Jean-Laurent a donc montré comment utiliser Cucumber.js et Zombie.js pour tester le site web Serpodile. A la fin de la démonstration, je suis convaincu qu’il est possible d’écrire des tests fonctionnels et de les exécuter rapidement. Jean-Laurent partage aussi son expérience acquise avec d’autr
es outils comme Abbot, HtmlUnit et enfin Selenium. Ce dernier, très populaire, a le défaut d’utiliser un vrai navigateur pour effectuer ses tests. C’est lent, et cela peut causer parfois des soucis de performances. Zombie.JS est un système basé sur Node.JS, sans navigateur, capable de tester finement une application Web. Et il est incroyablement rapide, ce qu’il nous démontrera par la suite.
Il montre aussi l’utilisation de CoffeScript, un langage transpilé vers du Javascript, qui permet d’écrire du code avec moins de cérémonial et plus rapidement qu’en Javascript natif. Enfin il montre l’utilisation de Cucumber.js, avec l’utilisation de la notation Gherkin, très populaire pour rédiger des tests :
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenario: A different situation
Il a ensuite effectué plusieurs démonstrations convaincantes pendant 20mn. Facilité d’écriture, rapidité d’exécution, moi j’ai été convaincu. Ne vous arrêtez pas au mot Javascript. Cette solution permet de tester n’importe quel site Web, qu’il soit en Ruby, en PHP, en Java ou en .NET. A connaitre donc.
Coté version, il recommande d’utiliser la version 1.4.1 de Zombie.js et de ne pas prendre la 2.0 pour l’instant. Il utilise aussi chai.j, une librairie Node.JS de tests et d’assertions BDD/TDD (should, expect, assertThat…)
Enfin il existe d’autres alternatives comme Karma Runner, dalekJS ou Casper.JS.
Karma Runner permet de tester avec différents navigateurs. Si vous faîtes de l’Angular.JS, il y a un module particuluer. DalekJS est aussi un moteur de tests qui permet de tester avec différents navigateurs. Il cite aussi Casper.JS, outil de scripting et de tests qui permet de parcourir et donc de tester un site, en utilisant Phantom.JS
En conclusion, l’écosystème Javascript est vraiment plus mature et plus dynamique dans ce domaine que le monde Java. Ce n’est pas tout à fait exact car il y a par exemple le projet FluentLenium qui booste de façon intelligente le projet Selenium. Le seul souci de Selenium, c’est qu’il ne s’adapte pas aux problèmes de l’appel de services asynchrones via Ajax. Combien de fois avons-nous repris des tests pour augmenter ou diminuer des boucles d’attente… car le test « ne passait pas avec 500ms de temps d’attente ». Si vous avez un retour sur ce point, je suis preneur. En tous les cas, Jean-Laurent l’a démontré, ce problème n’existe pas avec Zombie.js
Je voulais aussi écrire un article avec un collègue sur cette présentation très intéressante, mais tu nous as coiffés au poto !
Ton article est vraiment sympa. Juste deux petites corrections qui pourraient être utiles à certains : « Zombie.JS est un système basé sur Node.JS, sans navigateur, capable de tester finement une application Web », en fait Zombie.js ne fonctionne pas réellement « sans navigateur », c’est juste qu’il utilise son propre navigateur virtuel.
Et sinon c’est bien chai.js et non pas chai.j, mais comme tu as mis le lien directement, les gens s’en sortiront 🙂
Merci pour cet article en tout cas !
«En conclusion, l’écosystème Javascript est vraiment plus mature et plus dynamique dans ce domaine que le monde Java.»
On peut m’expliquer ce que vient faire la cette pique, gratuite, non-justifiée et inexacte (ne serait-ce que parce que Java et Javascript n’ont jamais été» mutuellement exclusifs, bien au contraire) ? Là ça ressemble à une phrase de fanboy sans discernement. Dommage, le reste de l’article est bien ….
Pour info, dans le monde java, il faut aller faire un tour du côté de assertJ (équivalent de chai.js), Mockito, JmockIt pour ne citer que ceux-là.
@gstr : en fait quand Nicolas dit « dans ce domaine », il parle de test d’UI, donc sa phrase n’est ni gratuite, ni injustifiée et encore moins inexacte. Ce n’était en rien « une pique », simplement un constat. Tous les frameworks que tu cites sont des frameworks de tests unitaires Java, rien à voir donc 🙂
@gstr : je confirme, je ne fais référence qu’aux tests UI, avec donc navigation. Je connais Selenium, qui effectue des tests navigateurs automatisés. Est-ce que tu en as d’autres ?
@gstr et @Maxime Schneider: Si le sujet vous intéresse, jetez un oeil à JWebUnit, il comble presque tous mes besoins de tests UI
Hello,
pour les services AJAX avec sélénium tu peux faire une méthode waitFor au lieu de faire un simple wait. Au lieu d’attendre 500ms en espérant que l’élément de soit pas trop lent à se mettre en place, tu peux faire une boucle et tester la présence de l’élément (avec un timeout) pour le renvoyer dès qu’il apparaît.
Ça permet de mettre un timeout relativement important en gardant un test « rapide ».
Par exemple: https://github.com/loicknuchel/starters/blob/master/seleniumRC-starter/src/org/knuchel/selenium/extentions/MyWebElement.java#L170
Mais dans tous les cas c’est assez périlleux de faire les tests avec sélénium et les questions de timing ne sont vraiment pas simples (de ma petite expérience…).
Salut Nicolas,
Merci pour cet article,
pour info tu peux aussi mixer selenium avec un headless js browser pour gagner en rapidité.
Jean-Laurent l’a t-il mentionné ?
cf. http://net.tutsplus.com/tutorials/javascript-ajax/headless-functional-testing-with-selenium-and-phantomjs/
Ca suffit pas ça?
http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/support/ui/FluentWait.html
Il y a aussi graphene de nos amis jboss (utilise avec Arquillian) qui permet de booster les perfs de selenium avec son web driver.
Merci pour l article
je voulais ajouter ceci dans mon commentaire :
https://github.com/arquillian/arquillian-graphene