Le Touilleur ExpressLe Touilleur ExpressLe Touilleur ExpressLe Touilleur Express
  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express

Live coding and testing with Zombie.JS, cucumber.js and folks at Codeurs en Seine 2013

    Home Java Live coding and testing with Zombie.JS, cucumber.js and folks at Codeurs en Seine 2013

    Live coding and testing with Zombie.JS, cucumber.js and folks at Codeurs en Seine 2013

    Par Nicolas Martignole | Java | 10 commentaires | 18 octobre, 2013 | 0 | 3 597 affichages
         

    tag_codeurs_en_seine

    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-de-morlhon-codeurs-en-seine

    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

     

    Articles similaires:

    Default ThumbnailCodeurs en Seine 2013 Default ThumbnailCITCON 2009 Done and Testing Default ThumbnailFinale 2013 de Code Story chez Google France Default ThumbnailJug Summer Camp ce vendredi en direct live
    bdd, js, tdd, test, web
    • Avatar
      Maxime Schneider 18 octobre 2013 at 14 h 26 min

      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 !

    • Avatar
      gstr 18 octobre 2013 at 14 h 29 min

      «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à.

    • Avatar
      Maxime Schneider 18 octobre 2013 at 14 h 42 min

      @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 🙂

    • Avatar
      Nicolas Martignole 18 octobre 2013 at 14 h 51 min

      @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 ?

    • Avatar
      Mathieu LE TIEC 18 octobre 2013 at 15 h 06 min

      @gstr et @Maxime Schneider: Si le sujet vous intéresse, jetez un oeil à JWebUnit, il comble presque tous mes besoins de tests UI

    • Avatar
      Loïc Knuchel 19 octobre 2013 at 16 h 38 min

      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…).

    • Avatar
      Francois 22 octobre 2013 at 10 h 36 min

      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/

    • Avatar
      Zboub 29 octobre 2013 at 15 h 14 min

      Ca suffit pas ça?

      http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/support/ui/FluentWait.html

    • Avatar
      regis 29 octobre 2013 at 16 h 17 min

      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

    • Avatar
      regis 29 octobre 2013 at 16 h 18 min

      je voulais ajouter ceci dans mon commentaire :
      https://github.com/arquillian/arquillian-graphene

    Recent Posts

    • GitHub Actions : le tueur de Jenkins ?

      Avouez-le : ce titre de blog est super racoleur. J’avais aussi pensé

      15 février, 2021
    • Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021

      Nous sommes en février 2021 pendant le 3ème confinement lié à la

      10 février, 2021
    • FizzBuzz en Java et Scala (surtout Scala)

      L’exercice FizzBuzz est un petit exercice très simple, à tester par exemple

      9 février, 2021

    Recent Tweets

    •  @steeve  Agree. Those conversations remind me the old Paris Java User Group beer talks we had after each event cc  @mfiguiere   @DidierGirard 

      5 hours ago
    • RT  @_yom_ : Allez Twitter sois sympa et passe le mot autour de toi : on cherche toujours la perle rare qui voudra bien donner de l'amour aux…

      9 hours ago
    •  @dorianmariefr  Ben ce sont les chiffres officiels (je fais ma DA cette semaine) 😉

      22 hours ago
    • Doctolib c’est 1580 personnes dont 350 personnes « Produits/Tech » (chiffre officiel jan 2021)

      24 hours ago
    •  @rophilogene  Par exemple Doctolib Médecin c’est un outil SaaS très simple qui remplace les vieux logiciels installé… https://t.co/selHtXAi8s

      24 hours ago

    Mots clés

    agile (18) ajax (11) Apple (11) architecture (6) barcamp (5) BarCampJavaParis (5) ddd (5) devoxx (33) esb (6) exo (6) flex (9) geek (5) google (11) grails (5) groovy (10) humeur (12) humour (7) independant (6) iphone (12) Java (77) javascript (7) jazoon (28) jboss (22) jboss seam (12) jsf (9) jug (16) Linux (11) mac (6) mule (5) parisjug (7) paris jug (22) pjug (6) play (8) playframework (6) portlet (5) recrutement (6) ria (8) Scala (21) scrum (44) spring (23) Startup (11) usi (21) usi2010 (9) web (16) xebia (7)

    Le Touilleur Express

    Contactez-moi : nicolas@touilleur-express.fr

    Suivez-moi sur Twitter : @nmartignole

    Copyright© 2008 - 2020 Nicolas Martignole | Tous droits réservés
    • A propos de l’auteur
    • A propos du Touilleur Express
    Le Touilleur Express