
Vous développez une application web en Java. Le couche présentation est assurée typiquement par un framework MVC situé côté serveur : Spring MVC, Struts 2, Tapestry ou bien encore JSF. Votre projet est parfaitement industrialisé : infrastructure de build sous maven, intégration continue, tests unitaires, tests Selenium, analyse qualimétrique via Sonar.
A priori, vous n’avez rien à envier à la richesse grandissante de l’écosystème JavaScript, de l’outillage et des frameworks MV* côté clients. Et pourtant, quelque chose vous manque cruellement. En effet, depuis que RIA et Ajax se sont imposés, votre application Java contient davantage de code JavaScript qu’il y’a 10 ans. S’appuyant sur des librairies telles que jQuery ou Underscore, ce code JavaScript est typiquement embarqué dans votre WAR. Pour le valider, les développeurs doivent démarrer leur conteneur web et accéder à l’écran sur lequel le code est utilisé. Firebug ou Chrome sont alors vos meilleurs amis pour la mise au point du script.
Ce code JavaScript n’est généralement pas documenté. Le tester manuellement demande du temps. Les modifications sont sources d’erreur. Tout changement est donc périlleux. Si, à l’instar de vos tests JUnit pour vous classes Java, vous disposiez de tests JavaScript, vous en seriez comblés. Or, c’est précisément ce qu’il vous manque. Et c’est là où Jasmine et son plugin maven viennent à votre rescousse.

Lire la suite…
De nos jours, l’utilisation d’un serveur d’intĂ©gration continue pour dĂ©ployer son application puis exĂ©cuter ses tests Selenium s’est relativement dĂ©mocratisĂ©e. NĂ©anmoins, l’investissement rĂ©alisĂ© pour l’écriture de ces tests peut rapidement ĂŞtre mis Ă mal par le coĂ»t associĂ© Ă leur maintenance. En effet, les tests d’IHM sont de nature plus instables que de simples tests unitaires. Outre des problĂ©matiques de rendu et de transversalitĂ© des fonctionnalitĂ©s testĂ©es, l’une des principales difficultĂ©s rĂ©side dans la rĂ©pĂ©tabilitĂ© des tests. Les donnĂ©es de test y jouent pour beaucoup. Cette difficultĂ© est dĂ©cuplĂ©e lorsque votre application repose sur une architecture SOA dont les services SOAP, XML ou bien REST sont hĂ©bergĂ©s par des tiers : vous n’avez aucune maitrise sur les donnĂ©es de l’environnement testĂ©, ni sur sa stabilitĂ©. Des tests qui Ă©chouent rĂ©gulièrement Ă cause de donnĂ©es ayant Ă©tĂ© modifiĂ©es rendent laborieuse la dĂ©tection de vĂ©ritables rĂ©gressions. Cet article propose une solution appliquĂ©e depuis 2 ans sur une application de taille modeste (35 000 LOC pour 20 Ă©crans).

Lire la suite…
Chez mon client, des tests de stress sont réalisés sur toute nouvelle version d’une application. Outre le fait de qualifier techniquement l’environnement de pré-production, ces tirs permettent de détecter toute dégradation des performances et de prévenir toute montée en charge induite, par exemple, par une nouvelle fonctionnalité. Plus encore, ils permettent de mesurer les gains apportés par d’éventuelles optimisations. Ces tests de stress sont réalisés à l’aide de l’outil Apache JMeter [1].
Afin de pouvoir comparer des mesures, les cas fonctionnels utilisés lors des tests doivent, dans la mesure du possible, être identiques aux précédents tirs, sachant que ces derniers peuvent dater de plusieurs mois. Entre temps, nombre d’évolutions ont été susceptibles de casser vos tests JMeter. A priori, vous avez donc 2 choix : soit vous les réécrivez, soit vous les maintenez à jour. Si vous en avez déjà écrit, vous vous doutez bien que maintenir dans la durée des tests JMeter a un cout non négligeable. Une 3ième solution présentée ici consiste à la générer !
J’ai la chance de travailler dans une équipe ou l’outil Selenium [2] de tests IHM est rentré dans les mœurs. L’automatisation de leur exécution y joue un rôle indéniable. Notre hiérarchie s’est fortement impliquée ; elle a investi de l’énergie et du budget. Un DSL a été mis au point pour faciliter leur écriture et leur maintenance. Alors quand on peut les rentabiliser encore davantage, autant le faire. J’ai donc proposé de ne maintenir que les tests Selenium et de générer les tests JMeter à partir de tests Selenium.
Cet article a pour objectif de vous présenter la démarche adoptée. Si vous êtes intéressés, vous pourrez librement l’adapter en fonction de votre contexte projet.

Lire la suite…
