Accéder au contenu principal

Intégration des tests fonctionnels CasperJS avec Grails



Introduction

Le but de cet article est de vous présenter un plugin Grails permettant d'instrumentaliser vos tests fonctionnels via CasperJS. Sans pour autant rentrer dans les considérations de la nécessité ou pas, de miser sur ce type de tests pour votre application, je présenterai néanmoins les grands principes de cette couche tout en espérant vous convaincre de l'intérêt et l'utilité de celle-ci.

Présentation du framework Grails et l'utilitaire CasperJS

"Grails parce que je le vaux bien ! - développeur anonyme
Et oui ! Car qui n'a jamais pesté contre son vieux legacy de dix ans, piégé de mille et un tricks en tous genres trouvés au petit bonheur la chance sur Stack Overflow ? Qui ne s'est jamais demandé pourquoi, il devait manipuler une stack technique aussi complexe, afin de produire un écran de gestion aussi simple que primordial pour le business. Ne cherchez pas, il faut passer à autre chose, à un niveau d'outillage vous permettant d'être réactif et pro, le tout dans un cadre sécurisé, j'ai cité Grails.
Groovy On Rails est un framework d'aide au développement d'applications Web (principalement), dit full-stack, car couvrant à tous les étages, les besoins d'une application moderne. C'est aussi un framework extrêmement populaire pour les raisons suivantes :
  • Grails permet de produire une application saine et robuste en très peu de temps via sa console et sa parfaite intégration aux principaux IDE du marché,
  • La gestion de son architecture interne plutôt orientée convention que configuration, limite le bruit nécessaire à l'organisation et au maintien de l'application,
  • Son extensibilité est sans limite grâce à son mécanisme de plugins, dont le but est d'étendre les capacités du framework, permettant ainsi, d'ouvrir ce dernier à des technologies comme par exemple CasperJS,
  • Et pour terminer, mentionnons, que l'on peut coder du Grails en Java et en Groovy, qui pour ce dernier est un langage ayant à mon sens, sa place parmi les plus grands. J'y ai pour ma part découvert un langage riche, puissant, surprenant et bien plus évolué que Java (qui a d'autres contraintes certes, mais ceci est une autre histoire...).
"CasperJS, parce qu'un bon ouvrier a de bon outils - développeur anonyme"
C'est tellement évident que l'on aurait tendance à l'oublier... Mais comme pour Grails, il est nécessaire de nos jours d'avoir à portée de main, des outils de testing modernes et robustes, capables de répondre aux exigences du marché. Quels sont ces besoins et ces exigences ?
  • Avoir un feedback rapide en cas de bugs, sur une application en production ou sur l'intégration continue,
  • Avoir un outil simple à mettre en oeuvre, capable de s'intégrer dans n’importe quelle infra (intra, PaaS...) et qui mérite mieux qu'une vieille bécane perdue entre deux bureaux de développeurs,
  • Avoir à portée de main, un outil simple, intuitif, qui se pilote et se maintien simplement via un langage de programmation connu de tous.
Vous savez à présent quoi faire de vos vieux tests Selenium... Mais si, ces fameux tests si compliqués à scripter et qui s'intègrent si mal dans votre SI. Ceux-la même que l'on s’obstine à supporter au point même de devoir désigner par Sprint, un responsable du CI, passant le plus clair de son temps à les maintenir ou les redémarrer... Je vous vois sourire !

Une vraie solution passe aujourd'hui par un outil capable de répondre à ces besoins : CasperJS. En effet, cet outil a eu la bonne idée d'hériter de PhantomJS, qui n'est autre qu'un moteur de rendu Webkit headless pilotable en JavaScript permettant la manipulation du DOM. L'intérêt d'avoir CasperJS au dessus de PhantomJS est de pouvoir définir de manière moins rudimentaire, des scénarios de tests ou de navigation, par le biais d'une API un peu moins rugueuse ; le tout éventuellement en CoffeeScript.

CasperJS Tests Runner Plugin for Grails


Comme son nom l'indique, le but de ce plugin est de s'intégrer dans le life-cycle de Grails, afin que ce dernier puisse lancer les tests développés par l'équipe développement.

La configuration


Bien que la page GitHub du plugin explique en détail la procédure d'installation et de lancement, voici les  étapes nécessaires à l'exécution de ce dernier :

  • Installer et ajouter dans votre path les outils CasperJS et PhantomJS,
  • Tester la bonne configuration de votre installation en lançant la commande suivante :
    • casperjs --version
    • Si votre installation est mauvaise, vous aurez alors un message indiquant la nature de l'erreur et à l'inverse le numéro de version,
  • Editer votre fichier Build.groovy afin d'y ajouter dans la section plugins, la configuration nécessaire :
    • test ":casper-runner:0.2",
  • Créer un répertoire casper dans test/,
  • Ajouter un fichier de tests écrit en JavaScript ou CoffeeScript, comme par celui-ci dans le répertoire test/casper,
  • Lancer à la racine de votre application Grails, la commande suivante, afin d'exécuter le test d'exemple :
    • grails test-app casper:
  • Et le tour est joué !

Si l'exécution du test s'est correctement déroulée, vous aurez à quelque chose près, la sortie suivante :

$ grails test-app casper:
| Executing following CasperJS test(s) file(s): [test_navigation_google.js]
| Executed 5 test(s) for test_navigation_google.js: 0 failure, 5 success
| Completed 1 casper test, 0 failed in 1415ms
| Tests PASSED - view reports in target/test-reports

Ainsi par le biais d'une commande Grails dédiée, vous serez capable de lancer à votre guise, votre batterie de tests fonctionnels, dont le résultat des opérations sera reporté dans un fichier xUnit à Grails, vous prévenant ainsi du succès ou de l'échec des ces derniers.

Limitations et évolutions du plugin


Si vous avez été un peu attentif précédemment, vous avez certainement pu remarquer que le numéro de version du plugin est de 0.2, ce qui signifie, qu'il est encore jeune.
Ainsi, si vous décidez de l'utiliser dans votre CI, vous devez disposer de CasperJS et PhantomJS dans votre path au moment de l’exécution de ce dernier. Il est prévu dans une future version, d'embarquer les deux compères si ils ne sont pas présent lors de l'installation du plugin, une issue GitHub est même prévue à cet effet.
De plus, pour que l'intégration soit totale, il ne faut pas oublier d'ajouter à la fonction run le code suivant indiquant à CasperJS, qu'il doit utiliser la sortie fichier XML pour le résultat au format xUnit :
this.test.renderResults(true, 0, this.cli.get('xunitFileName'));


Conclusion


Voilà, l'immersion dans la stack Grails au travers des tests fonctionnels CasperJS est terminée. Je pense que vous avez noté avec quelle facilité, on peut intégrer des tests pertinents et relativement simples à maintenir, pour peu que l'on s'en donne la peine et que l'on accepte un peu de configuration manuelle. A noter, que le plugin est compatible 2.0.1 > ce qui signifie que même vos anciennes applications ont le droit d'être sous l'égide de tests fonctionnels moderne et pour couronner le tout fun !

Commentaires

Posts les plus consultés de ce blog

Faire sa machine virtuelle sous Debian ARM avec QEMU

Introduction L'objet de ce article est de vous expliquer comment faire  pas à pas,  sa machine virtuelle Debian Wheezy   tournant sur un processeur ARM   avec QEMU . Il est relativement simple de trouver des ressources à ce sujet sur le Web, mais je voulais apporter ma pierre à l'édifice sous forme d'un petit  tutorial prêt à l'emploi. A propos d'ARM et d'émulation, il faut savoir qu'au jour d'aujourd'hui, VirtualBox est incapable de virtualiser un OS tournant sur ARM, cela m'a donc obligé à m'intéresser de plus prêt à QEMU. Et si vous vous demandez pourquoi, je veux émuler de l'ARM, vous le serez au prochain épisode... QEMU QEMU est un logiciel développé à l'origine par le célébrissime programmeur  Fabrice Bellard . Le succès de cet émulateur vient principalement du fait, qu'il est tout aussi capable d'émuler que de virtualiser. La principale différence entre l'émulation et la virtualisation est qu'un

Retour sur Rework

Je me suis pour une fois sorti la tête des ouvrages techniques, de mon GoogleReader/programming/languages et autres joyeusetés de ce genre, pour me plonger dans le livre à la mode, Rework . Ce livre co-écrit par Jason Fried et David Heinemeier Hansson est un cookbook destiné aussi bien aux boss, qu'à leurs employés, désirant comprendre et décrypter les clés de la réussite de cette entreprise : 37signals , qui est au passage la boite qui a crée le website Basecamp et le framework ROR . L'ensemble repose sur un enchainement intéressant de chapitres courts mais percutants, avec des illustrations assez plaisantes. Tout est écrit en noir & blanc dans un anglais assez compréhensif, qui permet de le terminer en un clin d'œil, si vous n'avez pas fait comme moi et pris des notes quasiment à chaque chapitre. Je ne vais pas coucher toutes mes notes sur cette page, mais vous en énumérez les premiers points qui m'ont le plus marqué, car ce livre a été pour moi et sera je

Releaser avec Maven sur github

Le but de l'exercice est de releaser un projet Maven simple en utilisant le maven-release-plugin via Cygwin sur la plateforme github . En effet, la procédure serait aussi simple que sur Subversion , à la condition d'avoir ses settings et ses POM au carré, ce que nous allons voir de suite. Pour mener à bien l'opération, les pré-requis sont les suivants : Avoir un environnement de développement sous Cygwin , le mien étant Windows XP SP3 / Cygwin 2.712 , / java 1.6.0_17 / git 1.7.1 avec une auto-complétion des commandes git bien pratique, Avoir une configuration Maven opérationnelle dans le sens où vous avez accès aux maximums de repositories publics et une plateforme d'hébergement/déploiement pour vos archives. La mienne étant Maven 2.2.1 / Nexus™ Open Source Edition 1.7.1. J'avoue avoir de la chance, car j'utilise pour mes tests, ma plateforme d'entreprise (chez Vidal) configurée aux petits oignons par mon collègue Thierry que je salue au pass