Cet article se propose de vous montrer comment réaliser de tels tests, avec un niveau d’isolation suffisant pour la parallélisation dans un processus multithread, tout en essayant de trouver le meilleur compromis avec le temps d’exécution de chaque test. Ces tests sont présentés dans une configuration très classique utilisant Spring et JPA/Hibernate.
L’implémentation utilise une base HSQLDB et quelques bibliothèques pour faciliter l’écriture du code, en essayant de rester aussi léger que possible. Les tests sont isolés pour que vous puissiez activer l’exécution parallèle du plugin Surefire de Maven au niveau des classes de test. Vous pourrez facilement dériver l’implémentation nécessaire à isoler vos tests au niveau des méthodes si vous le souhaitez.

Introduction

Un premier réflexe est de réaliser des tests contre une base de donnée existante. L’automatisation de ces tests mène très rapidement à des problèmes de reproductibilité et d’isolation, en particulier quand les traitements testés effectuent des opérations d’écriture dans la base de données, mais également parce que la base utilisée est souvent une base de développement que les développeurs peuvent être amenés à faire évoluer de manière incontrôlée. La solution immédiate est de créer une copie du jeu de données initial et de le recharger dans la base avant chaque test. Cette problématique, et sa conséquence, la gestion des jeux de données ont amené la création d’outils tels que DBUnit.

L’utilisation d’une base de données centralisée, même si elle est spécifique aux tests, amène son propre lot de problèmes : que se passe-t-il si plusieurs développeurs jouent leurs tests en même temps ? Les uns vont insérer leur jeu de données pendant que les autres font une écriture ; les tests ne sont pas isolés. Il faut créer une base de données par développeur.

Deux options s’offrent alors, la première consiste à créer un schéma pour chacun sur le serveur. Cela amène des problèmes de latences réseaux, de charge du serveur et rend impossible le travail en cas de coupure du réseau. Il vaut mieux pencher pour la seconde option et créer une instance sur la machine de chaque développeur. Comme ce sont souvent des machines de bureautique avec des disques lents, un SGBD complet qui n’est finalement presque pas utilisé et qui consomme de précieuses ressouces est mal venu, surtout lorsqu’il faut partager ces ressources avec un IDE, un serveur d’application, … Reste la possibilité d’utiliser une base de données embarquée comme HyperHSQL (HSQLDB), H2, Derby, etc. L’instance est créée par le processus du test et détruite lorsqu’il se termine. Il reste à y charger la structure des tables et le tour est joué.

Ces tests d’intégration joués séquentiellement peuvent encore s’avérer trop lent, surtout dans le cadre d’un build complet qui joue tous les tests. Il convient alors de les paralléliser.

Structure du projet

Partons d’un projet classique utilisant Spring et JPA/Hibernate, packagé avec maven. La structure de projet prend la forme suivante :

Dans le dossier main, on retrouve les entités du modèle de données, les DAOs avec respectivement une interface et une implémentation et le descripteur de l’unité de persistance JPA.

Dans le dossier test, les tests des deux DAOs, les fichiers de configuration XML Spring, un fichier de propriétés pour hsqldb et les deux jeux de données pour les tests au format XML.

Créer les tests avec spring & dbunit

Le code d’un test

AddressDaoTest.java

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"applicationContext-test.xml"})
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class,
                         DataSetTestExecutionListener.class})
@DataSet(value = "AddressDaoTest.xml")
public class AddressDaoTest {
    @Autowired
    private AddressDao addressDao;
    @Test
    public void testFindByAddressname() {
        Address user = addressDao.findByAddress("a");
        assertNotNull(user);
    }
    @Test
    public void testFindByAbsentAddressname() {
        Address user = addressDao.findByAddress("c");
        assertNull(user);
    }
}

Ce test est exécuté avec SpringJunit4ClassRunner qui créé le contexte Spring avec les fichiers indiqués dans l’annotation @ContextConfiguration et le met en cache.

La mise en cache est un détail important pour l’exécution de plusieurs classes de tests. Si vous avez plusieurs classes de tests, déclarant exactement la même annotation @ContextConfiguration qui sont lancées dans un même processus, seule la première aura besoin d’initialiser le contexte Spring. Les suivantes pourront réutiliser le contexte économisant ainsi : le parsing de la configuration, le scan du classpath à la recherche d’annotations ainsi que les diverses phases d’initialisations des beans utilisés dans le contexte.

L’annotation @TestExecutionListener fournie par spring-test permet d’enregistrer des classes qui peuvent se brancher dans le cycle de vie d’exécution d’un test (before test class, before test method, …). L’utilité des listeners utilisés ici est précisée un peu plus bas.

La configuration

Notre contexte de test contient les éléments standards d’un contexte Spring JPA/Hibernate mais quelques points méritent d’être notés pour que nous puissions revenir dessus.

La déclaration de la datasource hsqldb

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <property name="driverClassName" value="${ds.driver=org.hsqldb.jdbcDriver}"/>
    <property name="url" value="${ds.url=jdbc:hsqldb:mem:test}"/>
    <property name="username" value="${ds.username=sa}"/>
    <property name="password" value="${ds.password=}"/>
</bean>

La déclaration de la factory JPA/Hibernate

<bean id="jpaVendorAdapter" class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
    <property name="databasePlatform" value="${hibernate.dialect}<"/>
</bean>
<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="persistenceUnitName" value="pdbunit"/>
    <property name="jpaVendorAdapter" ref="jpaVendorAdapter"/>
    <property name="jpaProperties">
        <props>
            <prop key="hibernate.dialect">${hibernate.dialect}</prop>
            <prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto=update}</prop>
        </props>
    </property>
</bean>

Les listeners

DependencyInjectionTestExecutionListener

L’utilisation de ce listener défini par l’API spring-test permet simplement d’utiliser les annotations d’injection de dépendance (@Autowired,@Resource,…) sur des éléments de la classe de test. Ainsi, dans le test de DAO vu précédemment l’instance du DAO sera injectée avant l’exécution du test.

DataSetTestExecutionListener

Ce listener est défini dans l’API spring-dbunit et permet l’utilisation de l’annotation @Dataset sur une classe ou sur une méthode de test.

Cette annotation utilise dbunit pour charger un jeu de données avant chaque test et pour le supprimer après chaque test.

Par défaut, cette annotation cherche un fichier nommé dataSet.xml dans le même package que la classe de test qui porte l’annotation. Il est possible de changer le nom du fichier, d’en charger plusieurs, bref de choisir son jeu de données.

Un premier palier

À ce stade, nous avons donc des tests qui chargent leur jeu de données dans une base mémoire avant de s’exécuter. Isolés du monde extérieur ils ne risquent pas d’échouer à cause d’un changement involontaire par une autre personne, d’une perte de connexion réseau ou d’une autre exécution de la suite de test par un second développeur.

Parallèliser les tests dans maven

En l’état actuel, les tests ne peuvent pas être exécutés en multi-thread au sein d’un même processus, ce que sait faire le plugin surefire de maven en charge de l’exécution des tests. Unitairement rapides, la contrainte de les exécuter en séquentiel empêche de profiter pleinement des processeurs multi-cores des ordinateurs modernes. Les tests ne sont utiles que si ils sont exécutés et ils ne sont exécutés que si ils sont suffisamment rapides.

Une base de donnée par thread

Ce qui fait échouer l’exécution en mode multi-thread, ce sont les collisions entre les différents jeux de données manipulés par dbunit (deux jeux de données chargés en même temps peuvent modifier le résultat de certaines requêtes), sans compter les opérations d’écritures potentielles des traitements testés. Il faudrait que chaque test dispose de sa propre base de donnée.

ThreadUniqueDriverManagerDataSource

public class ThreadUniqueDriverManagerDataSource extends
  DriverManagerDataSource {
 @Override
 public String getUrl() {
  long tId = Thread.currentThread().getId();
  return super.getUrl() + tId;
 }
}

En utilisant cette surcharge de DriverManagerDataSource comme classe d’implémentation pour votre dataSource, chaque thread accédera à sa propre base de données mémoire.

<bean id="dataSource" class="fr.xebia.jdbc.datasource.ThreadUniqueDriverManagerDataSource">
    <property name="driverClassName" value="${ds.driver=org.hsqldb.jdbcDriver}"/>
    <property name="url" value="${ds.url=jdbc:hsqldb:mem:test}"/>
    <property name="username" value="${ds.username=sa}"/>
    <property name="password" value="${ds.password=}"/>
</bean>

Il reste un problème: le contexte Spring n’est chargé et initialisé qu’une seule fois, par conséquent Hibernate ne créé la structure des tables qu’une seule fois. Si nous tentions d’exécuter nos tests, le « premier » – celui dans lequel le contexte Spring est initialisé – réussirait. Les autres échoueraient en se plaignant que les tables nécessaires à l’insertion de leur jeu de données n’existent pas.

Il est possible de forcer le runner de Spring à réinitialiser un contexte pour chaque classe de test, mais cette initialisation est coûteuse et tout ce dont nous avons besoin est de créer les tables dans la base de données, tout le reste fonctionne très bien sans réinitialisation.

Recréer la structure de la base de données dans chaque thread.

Sachant que les listeners de test sont exécutés dans l’ordre de leur déclaration, il nous faut donc un listener qui soit exécuté après la création du contexte mais avant le chargement des données et qui se charge de recréer la structure. Nous avons déjà du code capable de recréer la structure dans Hibernate, il faut donc l’exécuter à nouveau pour chaque nouvelle base. La dernière donnée est le niveau de parallélisation, le maven-surefire-plugin est capable de paralléliser aux niveaux : « classes », « methods », « both ». Il faudra adapter le listener en fonction du niveau choisi.

Dans la suite nous allons chercher à exécuter le code parallélisé au niveau « classes », notre TestListener peut donc s’exécuter « beforeTestClass ».

JpaHibernateDbSetupTestListener

Le code du listener suivant est lié à l’utilisation JPA/Hibernate. Il ne devrait pas être très difficile de dériver un listener pour d’autres solutions de persistance, du moment que l’on sait créer la structure de la base de données.

public class JpaHibernateDbSetupTestListener extends AbstractTestExecutionListener {
    @Override
    public void beforeTestClass(TestContext testContext) throws Exception {
        super.beforeTestMethod(testContext);
        Map<String, EntityManagerFactoryInfo> emfsMap = testContext.getApplicationContext().getBeansOfType(
                EntityManagerFactoryInfo.class);
        for (Map.Entry<String, EntityManagerFactoryInfo> emfByName : emfsMap.entrySet()) {
            EntityManagerFactoryInfo entityManagerFactoryInfo = emfByName.getValue();
            String puName = entityManagerFactoryInfo.getPersistenceUnitInfo().getPersistenceUnitName();
            HibernatePersistenceCacheUnit persistenceInformation = HibernatePersistenceCache.getPersistenceInformation(puName);
            SchemaExport schemaExport = new SchemaExport(persistenceInformation.getHibernateConfiguration(),
                    persistenceInformation.getSettings());
            schemaExport.execute(false, true, false, false);
        }
    }
}

Cette implémentation nécessite des modifications supplémentaires à notre environnement de test. Elle repose sur la présence d’un cache des informations de persistance (HibernatePersistenceCache) dans lequel sont stockées les informations nécessaires à la recréation du SchemaExport.

Les informations de configuration manipulées par SchemaExport ne sont normalement pas accessibles une fois l’initialisation d’Hibernate terminée. Il faut donc les capturer lors de l’initialisation et les ajouter au cache. Pour cela nous allons devoir remplacer l’adaptateur Spring org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter par une implémentation maison.

public class HibernateJpaVendorParallelAdapter extends HibernateJpaVendorAdapter {
  private final PersistenceProvider persistenceProvider = new CachingHibernatePersistence();
  @Override
  public PersistenceProvider getPersistenceProvider() {
    return this.persistenceProvider;
  }
}

Le remplacement se fait dans le fichier de définition du contexte Spring, ce qui explique l’externalisation de la définition du jpaVendorAdapter :

<bean id="jpaVendorAdapter" class="fr.xebia.test.utils.parallel.jpa.hibernate.HibernateJpaVendorParallelAdapter">
        <property name="databasePlatform" value="org.hibernate.dialect.Oracle10gDialect"/>
</bean>

La capture des informations de configuration peut alors se faire dans CachingHibernatePersistence :

public class CachingHibernatePersistence extends HibernatePersistence {
  @Override
  public EntityManagerFactory createEntityManagerFactory(String persistenceUnitName, Map overridenProperties) {
    Ejb3Configuration cfg = new Ejb3Configuration();
    Ejb3Configuration configured = cfg.configure(persistenceUnitName, overridenProperties);
    cacheConfig(persistenceUnitName, null, overridenProperties, configured);
    return configured != null ? configured.buildEntityManagerFactory() : null;
  }
  @Override
  public EntityManagerFactory createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map) {
    Ejb3Configuration cfg = new Ejb3Configuration();
    Ejb3Configuration configured = cfg.configure(info, map);
    cacheConfig(info.getPersistenceUnitName(),info, map, configured);
    return configured != null ? configured.buildEntityManagerFactory() : null;
  }
  private void cacheConfig(String name, PersistenceUnitInfo info, Map map, Ejb3Configuration configured) {
    if (configured != null) {
      HibernatePersistenceCacheUnit cachedInfo = new HibernatePersistenceCacheUnit(name);
      cachedInfo.setPersistenceUnitInfo(info);
      cachedInfo.setPropertyMap(map);
      cachedInfo.setHibernateConfiguration(configured.getHibernateConfiguration());
      cachedInfo.setSettings(configured.buildSettings());
      HibernatePersistenceCache.addPersistenceInformation(cachedInfo);
    }
  }
}

HibernatePersistenceCacheUnit est un simple conteneur pour les données qui nous intéressent :

public class HibernatePersistenceCacheUnit {
    private final String name;
    private PersistenceUnitInfo persistenceUnitInfo;
    private Map<String, Object> propertyMap;
    private Configuration hibernateConfiguration;
    private Settings settings;
    private SessionFactory sessionFactory;
    //...
}

et enfin le cache lui-même est une implémentation basique utilisant une simple HashMap :

public class HibernatePersistenceCache {
  private static final Map<String, HibernatePersistenceCacheUnit> persistenceInformationMap = new HashMap<String, HibernatePersistenceCacheUnit>();
  public static void addPersistenceInformation(HibernatePersistenceCacheUnit persistenceInformation) {
    assert(persistenceInformation != null);
    assert(persistenceInformation.getName() != null);
    persistenceInformationMap.put(persistenceInformation.getName(), persistenceInformation);
  }
  public static List<HibernatePersistenceCacheUnit> getPersistenceInformations() {
    return new ArrayList<HibernatePersistenceCacheUnit>(persistenceInformationMap.values());
  }
  public static void clearPersistenceInformations() {
    persistenceInformationMap.clear();
  }
  public static HibernatePersistenceCacheUnit getPersistenceInformation(String name) {
    return persistenceInformationMap.get(name);
  }
}

Il ne reste plus qu’à déclarer le listener au bon endroit dans le test :

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"applicationContext-test.xml"})
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class, JpaHibernateDbSetupTestListener.class, DataSetTestExecutionListener.class})
@DataSet(value = "AddressDaoTest.xml")
public class AddressDaoTest {
    @Autowired
    private AddressDao addressDao;
    @Test
    public void testFindByAddressname() {
        Address user = addressDao.findByAddress("a");
        assertNotNull(user);
    }
    @Test
    public void testFindByAbsentAddressname() {
        Address user = addressDao.findByAddress("c");
        assertNull(user);
    }
}

et à activer la parallélisation des tests lors de l’exécution du plugin surefire

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.11</version>
    <configuration>
        <parallel>classes</parallel>
    </configuration>
</plugin>

Vos tests sont maintenant suffisament isolés pour que surefire puisse exécuter vos classes de tests en multi-thread.

Autres pistes de listeners

Il existe plusieurs moyens de résoudre le problème du rechargement de la structure de la base de données dans les bases créées en mémoire. Si vous disposez d’un outil de migration comme flyway, ou que votre équipe garde scrupuleusement à jour un fichier avec la totalité de la structure de données de la base, vous pouvez créer votre propre listener pour charger la base à partir de cette référence. Vous pouvez également initialiser une base de données fichier plutôt que mémoire et en créer des copies qui seront utilisées par les différents Threads.

Des bases de données et des dialectes

Utiliser une base de donnée mémoire n’est pas complètement anodin. Chaque SGBD parle son propre ‘dialecte’ de SQL, souvent un sous-ensemble auquel peut s’ajouter des extensions spécifiques de l’éditeur.
L’idée dans cet article est de maximiser les gains obtenus en testant les commandes SQL qui sont partagées entre votre SGBD de production et la base mémoire utilisée. L’utilisation de moteurs ORM comme Hibernate tends à normaliser le sous-ensemble de commandes utilisées, ce qui facilite la compatibilité pour la plupart des requêtes. Il peut néanmoins être nécessaire d’utiliser des requêtes natives pour certaines optimisations ou pour certains cas d’utilisation spécifiques. Même comme ça, les cas d’incompatibilités peuvent être réduit par l’utilisation d’une base mémoire adaptée. Recherchez la base mémoire qui a un dialecte aussi proche que possible de celui de votre moteur de production pour pouvoir tester autant de requêtes que possible.

Le code qui malgré tout restera incompatible pourra être testé dans le cadre de tests d’acceptation sur un environnement complet. Respectez la loi de Pareto en dépensant 20% d’effort pour 80% des gains, et ne modifiez pas une requête optimisée pour votre moteur de production juste pour pouvoir la tester dans un moteur de test.

Code de l’article

Vous retrouverez sur github

• le projet de démo qui a servi de base au code de l’article
• un projet contenant l’implémentation du listener et du cache sous forme de librairie maven.

Pour faire simple, imaginez que sur un seul écran vous puissiez voir en un clin d’œil l’état de vos builds (succès/instabilité/échec), le nombre de tests unitaires et d’intégration agrémenté de métriques telles le nombre de lignes de code, la couverture de code et le respect des normes de codages.

Mieux qu’un long discours, nous vous proposons une courte vidéo de 3 minutes qui démontre la facilité avec laquelle vous pouvez démarrer facilement avec l’outil.

Si l’outil vous intéresse, il est disponible au téléchargement et le code source est à votre disposition sur github.

Si vous désirez en savoir plus sur le développement de ce projet, nous vous proposons une rétrospective de ces derniers mois, en partant de la genèse du projet jusqu’à son état actuel.

La genèse

Visuwall est un projet imaginé et développé par deux Xebians : Arnaud Lemaire et Julien Smadja. L’idée a germé en janvier 2011 à l’occasion d’une mission axée sur l’amélioration de la testabilité d’un projet Java. Sa première étape fut d’écrire plusieurs dizaines de tests d’acceptance afin de valider le bon fonctionnement d’un webservice REST.

Les tests échouaient souvent et pouvaient durer plusieurs heures suivant l’environnement ciblé. Nous voulions connaître l’état de chaque environnement immédiatement et surtout, rendre l’information visible aux personnes extérieures. Le premier réflexe a bien sûr été de récupérer une unité centrale, un écran et d’installer un plugin Hudson capable d’afficher un « mur » de projets.

Ensuite, nous avons commencé à tenter de l’adapter graphiquement : changer la taille des polices, des blocs, cacher les informations non pertinentes, en afficher d’autres, etc. Un premier fork du plugin a donc été fait sur Github mais le cycle de développement n’était pas optimal : difficulté à tester, redéploiement du plugin, vérifications manuelles, etc.

La customisation du plugin n’étant pas viable, nous décidons de créer notre propre logiciel, adapté à nos besoins et ouvert à plusieurs outils. Visuwall était né… Enfin, ce nom n’est pas d’origine, le nom de code était Jbiniou puis JWall, ProjectWall et enfin, un matin, il fut baptisé officiellement Visuwall, une simple contraction des termes Visual et Wall.

Visuwall sera développé en parallèle de notre projet chez notre client, dans un cadre open source (Apache Software License 2), hébergé sur Github et codé en Java.

Technologiquement parlant : une base de données embarquée HsqlDb, une couche de persistence JPA2/Hibernate 3, une couche service Spring3/Spring MVC et une interface graphique Html/Javascript utilisant jQuery.

Rapidement, le projet est découpé en plusieurs modules, le core, l’interface web et les plugins. Il était très important que Visuwall soit capable d’être étendu par des plugins que nous avions d’abord catégorisés en deux groupes: les plugins des outils de builds (Hudson, Jenkins) et les plugins des outils de qualité (Sonar). Comme l’écriture d’un plugin se doit d’être simple, le design d’une API publique a été amorcé. Il s’agit principalement de remplir au maximum le contrat imposé par le moteur de Visuwall. Par exemple, un plugin doit être capable de fournir la liste des projets, la durée de tel ou tel build, le nombre de tests, etc.

Après plusieurs mois de développement, dans des endroits insolites comme les Bus, Metro, Rer et autres salles d’attente, le projet a été présenté lors du XKE de Juin afin de recueillir les premiers avis de nos collègues Xebians et pourquoi pas, les inciter à installer cette version 0.1 chez leurs clients.

À la suite des premiers retours (bugs et améliorations) nous avons travaillé sur une refonte totale (notamment sur l’API des plugins).

Modularité

Au fur et à mesure du développement, nous nous apercevons que certaines parties de notre code constituent à elles seules des projets à part entière. Nous avons donc déplacé ces projets dans un repository Github séparé. Ainsi, la communauté pourra se servir facilement de ce qui a été commencé pour Visuwall et utilisable dans un autre contexte. C’est notamment le cas des parties clientes de Bamboo, TeamCity, Hudson, Jenkins, Sonar (projet nommé Clients), mais également la partie validation des formulaires d’où naquit une librairie de validation (Client Bean Validation) qui est une implémentation en Javascript de la JSR303 pour la validation coté client des objets du serveur.

Pour améliorer la modularité du projet nous travaillons actuellement sur une transformation des clients en bundle OSGI afin de pouvoir charger et décharger des plugins à la volée pendant que l’application tourne. Cette évolution nous permet à la fois de mieux appréhender le coté modularité de l’OSGI mais également d’apporter une plus grande flexibilité à l’application. À terme, l’ajout du moteur OSGI permettra de faire fonctionner toute l’application avec des modules customisables, remplaçables et extensibles.

L’aventure continue

Notre travail sur Visuwall ne fait que commencer, nous avons encore des anomalies à corriger et des fonctionnalités à implémenter. Nous espérons avoir un maximum de retours de la part de la communauté pour pouvoir proposer un logiciel de qualité et utilisable dans le cadre de tous vos projets.

Visuwall a été présenté à CITCON 2011 devant quelques personnes dont un représentant de JetBrains. Nous allons prochainement prendre contact avec lui pour discuter des différentes améliorations que nous souhaiterions dans l’API REST de Teamcity !

C’est à ce titre que j’interviendrai le Mardi 24 Mai lors d’une présentation sur la dette technique. Le but sera de sensibiliser les futurs diplômés aux conséquences d’une dette non gérée sur les projets logiciels. Nous étudierons notamment les mécanismes de la dette et des bonnes pratiques pour la résorber.

Ceci est une fiction. Toute ressemblance avec des personnes existant ou ayant existé serait totalement fortuite.

Palais de justice de Paris, lundi 21 mars.

Une fois n’est pas coutume, des développeurs sont assis sur le banc des accusés! Ils sont inculpés de faire perdre des millions d’euros à nos chères compagnies du CAC40 en écrivant du code voué à crouler sous son propre poids.

Mr Tedd, praticien du Test Driven Development, est aujourd’hui jugé ainsi que quelques uns de ses collègues : Mr Whatever, Mr Guru, Mrs Clickaway et Mr Testafter.

Prévoyant et confiant, il sera défendu par son avocat : Maître Darrow. Ils ont convenu ensemble de la stratégie à adopter: il faudra pointer du doigt les mauvaises habitudes souvent utilisées et mettre en avant les bonnes pratiques qu’il a appliqué tout au long des projets qui lui ont été confiés.

L’audience est ouverte

Le Président, Mr Beck, ouvre la séance en rappelant les chefs d’accusations aux jurés:

• Le code applicatif contient trop de bugs
• Le code applicatif n’est pas testé
• Le code applicatif est pour la plupart du temps incompréhensible et reste trop volumineux pour le nombre de fonctionnalités
• La modification et l’amélioration du code applicatif existant est trop risqué à entreprendre

La parole est à la défense. Maître Darrow, soucieux de capter l’attention de son audience, rappelle le contexte:

Nous sommes en 2011. Dans les missions dans lesquelles mon client, Mr Tedd, intervient, écrire du code représente 80% de son temps. Ce code capture des règles métiers plus ou moins complexes et qui évoluent dans le temps. Visuellement son travail se traduit souvent par ce qu’on appelle un front end sur lequel un utilisateur tel que vous et moi pouvons interagir. Un bon exemple serait un site de réservation de billets de train au niveau Européen. Vous voyez donc, Messieurs et Mesdames les jurés que l’enjeu est de taille, l’erreur coûte chère et qu’elle n’est donc pas acceptable.

Aujourd’hui, je vais vous démontrer que mon client, Mr Tedd, adopte les pratiques adéquates pour rendre son code fiable, évolutif et pérenne.

Laissez-moi d’abord vous présenter quelques types classiques de développeurs. Si je n’enlève rien aux connaissances techniques et aux talents d’ingénieurs de ces personnes, je leur reprocherais cependant une attitude trop laxiste quant à la fiabilité et la pérennité du code qu’ils soumettent mais aussi une négligence au regard des méthodes qui permettraient d’améliorer considérablement la qualité globale des projets auxquels ils participent.

Permettez-moi de commencer par le cas de Mr Whatever.

Mr Whatever

Tous les regards se tournent vers ce grand gaillard assis au bout du banc des accusés.

Mr Whatever, si vous me permettez de vous citer, vous m’avez dit :

« Moi je fais juste confiance à mon code. Il compile c’est donc qu’il fonctionne. »

Je pense que Mr Whatever n’est jamais resté assez longtemps dans les entreprises pour lesquelles il travaillait pour savoir que son code en production posait plus de problèmes qu’il n’en résolvait. Je rappelle pour les profanes dans l’assistance, que la production est la plateforme exposée au grand public donc aux vrais utilisateurs. C’est dans cet environnement que la charge sur le système se révèle soutenue et que, potentiellement, tous les chemins possibles dans le code écrit sont réalisés en concurrence !

Le problème de Mr Whatever est qu’il ne sait réellement si son code fonctionne que lors de la phase de tests intensifs. Pour lui, tester c’est la tâche de ce que l’on appelle l’équipe de QA, tiré de l’anglais Quality Assurance, et qui s’assure de la qualité du logiciel fournit. Si son code ne fonctionne pas, ils le lui indiqueront et il corrigera. On voit bien que sa responsabilité de fournir du code qui fonctionne lui échappe.

L’avocat se tourne vers l’audience et continue :

Nous ne nous attarderons pas plus sur le cas de Mr Whatever, il appartient à une génération un peu dépassée par les événements.

Cette dernière phrase entraine de légers gloussements dans l’assistance.

Mr Guru

Maître Darrow, après avoir jeté un rapide coup d’œil aux papiers étalés sur son bureau, se tourne vers la personne assise aux côtés de Mr Whatever.

Passons au cas de Mr Guru. Cas intéressant puisqu’il représente l’archétype de l’informaticien auquel on accorde toute sa confiance !

Ses connaissances et son expérience en font un expert dans l’écriture du code. Cependant, il ne teste jamais ce qu’il écrit. Il n’introspecte pas. Perte de temps pour lui ! Il a écrit assez de plateformes pour savoir comment écrire la vôtre. Très bien. Nous aurons alors un code de qualité. Cette affirmation est correcte si votre équipe n’est formée que de Mr Guru ! Situation atypique s’il en est, et bon courage pour les batailles d’ego. Mais bon … passons.

L’avocat lève le bras pointant l’index vers le plafond et lance :

Si notre postulat de départ est que les entreprises ne travaillent qu’avec des profils tels que celui de Mr Guru, voici les problèmes que cela entrainerait :

Maître Darrow marque un silence pour permettre aux jurés de bien se concentrer sur ce qui va suivre.

Le premier problème serait une pénurie rapide de Mr Guru sur le marché. Toutes les entreprises ne pourraient pas en recruter et seraient dans l’incapacité de produire des applications de qualité. Un peu fantasque je vous l’accorde, mais totalement valide avec le postulat de départ.

Le deuxième problème impacterait le budget de l’entreprise. Un Mr Guru cela coûte cher ! Combien seriez-vous prêt à dépenser pour une armée de Mr Guru ?

Le dernier souci, et non des moindres, serait de s’assurer qu’on ne recrute que des Mr Guru. S’il y a un responsable des ressources humaines dans la salle, il m’accordera que la tâche se révélera ardue. Par ailleurs, je note aussi qu’il arrive à Mr Guru d’être fatigué ou d’être ennuyé, Guru ou pas, il reste humain. De ce fait, il est toujours possible qu’un expert introduise des erreurs dans votre code de production sans le vouloir.

De plus une question se pose. Faut-il bannir les développeurs juniors de votre équipe de développement ? Avons-nous peur qu’ils insèrent des erreurs dans le code ? Un bon manager vous dira que cela serait une faute. Une équipe doit être hétérogène en caractère. Pourquoi se couper du dynamisme des développeurs juniors, de la facilité avec laquelle ils manient les dernières technologies et de leur passion encore verte pour la programmation ?

Après une longue pause, l’avocat fixe chaque membre du jury tour à tour, et conclut :

Nous voyons bien qu’en réalité une équipe est constituée de profils différents et hétérogènes en compétence. Il nous faut donc une pratique commune de développement qui nous assure que Mr Guru et son collègue, plus junior, écrivent leur code d’une manière uniforme et testée sans porter atteinte à leur créativité.

Dans la salle, quelques personnes opinèrent du chef. Sûrement des développeurs!

Mrs Clickaway

L’avocat se rapproche de quelques pas du jury tout en désignant de la main la jeune femme assise au milieu du banc des accusés.

Maintenant le cas touchant de Mrs Clickaway. Mrs Clickaway est bien intentionnée. Elle veut savoir si son code fonctionne. Pour cela elle adopte un cycle rapide d’écriture de code, et de déploiement de son application dans son environnement local. Pour tester, elle clique et re-clique jusqu’à ce qui lui semble avoir parcouru tous les recoins des fonctionnalités qu’elle a implémentées. Pourtant, Mrs Clickaway utilise très mal son temps de développement. Pour les plus techniciens d’entre vous, je dirais qu’elle oscille entre stacktrace, long démarrage de serveur et debuging en tous genres !

En effet, alors qu’elle aurait l’opportunité d’écrire son code tout en l’introspectant, grâce aux trés bonnes librairies logicielles mises à disposition aujourd’hui, elle choisit de tester en mode boite noire. Pour les profanes dans la salle, le mode boîte noire est une série de tests qui se fait à un haut niveau de l’application sans se préoccuper réellement de la structure et du fonctionnement interne.

Je reproche donc à Mrs Clickaway de ne pas se concentrer sur son coeur de métier qui est la production d’un code propre et fiable. Pour être franc, je pense que Mrs Clickaway n’est jamais sûre de ce qu’elle écrit et qu’elle veut se donner bonne conscience avant de livrer son code à l’exploitation.

Je vous le dis, ne pas choisir l’introspection, c’est ne pas choisir de réfléchir sur ce que l’on produit et c’est ne pas choisir l’amélioration de son propre code. Mesdames et Messieurs les jurés, vous m’accorderez que c’est un peu surprenant et relève d’un comportement irresponsable pour un développeur.

Sur le banc des accusés Mrs Clickaway semble anéantie et confuse par cette série d’accusations.

Mr Testafter

Passons maintenant à mon cas favori. Mr Testafter.

Mr Testafter est sur la voie de la rédemption, seulement il a pris à gauche alors qu’il fallait prendre à droite ! Que je vous explique. Mr Testafter a bien compris qu’il fallait tester son code. Cependant, il écrit les tests après avoir écrit ce fameux code de production. Normal vous me direz. Eh bien non ! Cela pose plusieurs problèmes:

Comme tous les développeurs, Mr Testafter passe beaucoup de temps à écrire son code. Quand il en a enfin fini, c’est un soupir de soulagement avec une pause café bien méritée. Enfin jusqu’à ce qu’il réalise qu’il n’a écrit aucun test ! Pour ne rien arranger, il a déjà indiqué fièrement à son manager que son travail était fini. Qu’à cela ne tienne, il va ajouter rapidement les tests, parce qu’après tout, il n’a pas que ça à faire.

C’est à ce moment qu’il doit faire un effort non négligeable: se remémorer les spécifications, imaginer des cas d’utilisations pour finalement… relire son code afin de savoir quoi tester !

L’avocat lance un regard vers Mr Testafter sur le banc des accusés. Ce dernier fixe le plafond.

Idéalement, s’il veut que ses tests soient utiles, c’est-à-dire compréhensibles par un autre développeur, clairs, découpés en spécifications et couvrant toutes les fonctionnalités, il doit reprendre sa réflexion à zéro.

Cependant, Mr Testafter à ce moment précis est pressé. Il n’adoptera pas une démarche d’écriture « fonctionnalité par fonctionnalité ». Plus grave, il ne pensera pas aux effets de bord, car puisque son code est déjà écrit, il est censé fonctionner ! Summum du contre-sens, pour les praticiens du TDD dans la salle, Mr Testafter ne passe pas par la phase d’un test qui échoue. En réalité, Mr Testafter ne voit aucun test échouer ! Bizarre pour quelqu’un qui veut savoir si son code fonctionne.

Une fois les tests ajoutés, laissez-moi vous décrire le résultat, cela se vérifie presque à chaque fois. Il y a toujours plus de code généré qu’il n’en faut et le code contient de la duplication. Mr Testafter n’est pas dans une optique de code minimal pourtant si importante dans les énormes bases de code d’aujourd’hui. Les tests sont désordonnés, ne sont pas organisés en terme de fonctionnalités et contiennent eux aussi de la duplication.

Invariablement aussi, une fois les tests ajoutés, le code restera tel qu’il a été écrit à l’origine. Pas d’optimisation, de minimalisation ou de recherche d’expressivité du code. Le plus grave cependant est d’obtenir ce que l’on appelle un effet gruyère sur la classe testée: des bouts de code resteront non testés. Pour ceux qui me suivraient encore dans l’assistance, je ne vous conseille pas de refactorer du gruyère !

Sur cette dernière phrase, l’audience se partage entre face crédules et sourires.

Mr Tedd – Vers un code agile

Il est l’heure maintenant pour Mr Darrow de défendre son client. Il tient à expliquer aux jurées les principes fondamentaux sur lesquelles repose la méthode que son client Mr Tedd utilise. Il enchaine alors :

A travers les différents profils que je vous ai présenté, nous avons pu voir les insuffisances de certaines techniques de développement.

Laissez-moi donc maintenant vous résumer la manière d’écrire du code applicatif la plus à même à répondre à la problématique de tolérance au changement du monde du logiciel. C’est celle que pratique mon client. C’est le Test Driven Development. Cette méthodologie se résume avec la phrase suivante :

Tout code de production a été écrit pour faire passer un test qui au départ échouait.

Ce postulat pour certains peut sembler abstrait, cependant il se met en pratique tous les jours avec succès. Laissez-moi maintenant énumérer les corollaires directs de ce postulat.

Dans la salle on aurait pu entendre une mouche voler. L’avocat commence à énoncer :

Tout code de production est donc testé. Il n’y a pas plus de code que de fonctionnalités voulues et votre base de code est donc minimale. Toute fonctionnalité étant couverte par un test, vous savez instantanément lorsqu’un test échoue qu’une fonctionnalité n’est plus respectée et vous pouvez prendre aussitôt les mesures appropriées.

Ce code, proprement testé, vous pouvez le simplifier, l’améliorer et le nettoyer sans risque. C’est ce que l’on appelle le refactoring. Votre code devient par conséquent malléable, flexible et donc agile. C’est le moyen d’éviter que votre code ne s’effondre sous son propre poids !

L’avocat continue :

Mesdames et Messieurs les jurés, je vous le demande : Pour ceux qui connaissent le monde du logiciel, quel est le mot le plus important dans l’agilité?

Au vu des visages dubitatifs du public, et de cette femme âgée assise au premier rang qui avait commencé à tricoter, Maître Darrow comprit qu’il aurait à apporter lui-même la réponse.

Le Feedback ! Voilà le concept le plus important à mettre en place. Le Test Driven Development vous permet de mettre en place la plus petite boucle de feedback du monde agile. Instantanément vous savez si votre code répond à vos exigences.

Alors que Mr Darrow est au beau milieu de la défense de son client, le président Mr Beck, avec un geste d’impatience de la main, déclare :

Merci Mr Darrow. Cependant, avant que vous poursuiviez, l’avocat de la partie civile souhaite interroger maintenant votre client Mr Tedd. Et exceptionnellement, je ly’autorise.

Mr Darrow ne peut qu’abdiquer et Mr Tedd se dirige alors vers la barre pour être interrogé. C’est alors qu’un petit homme au front suintant, très agité, s’avance au centre. C’est Mr Pascal, l’avocat de la partie civile. Le contre interrogatoire peut commencer.

La suite du procès dans un prochain article.

Le framework The Grinder

C’est quoi The Grinder ?

The Grinder est un framework de test de charge « Jython-based scripting » écrit en Java. Il est open source (sous licence BSD) et  hébergé chez sourceForge.

Il permet de tester:

• Les serveurs web en mode HTTP /HTTPS.
• Tout ce qui vit dans un serveur d’application (Web service SOAP/REST, EJB, JMS,…)
• Les bases de données avec JDBC.
• Les servers FTP, POP3, SMTP, LDAP.

The Grinder s’exécute sur une plateforme supportant une version Java 1.4 ou supérieur.

Il peut être utilisé à des fins telles que :

• Test fonctionnel : contrôler le rendu de l’application par rapport au résultat attendu.
• Test de charge : vérifier que l’application peut supporter une charge donnée.
• Test de capacité : connaître la charge maximale supportée par l’application avant l’apparition d’erreurs
• Test de stress : vérifier la stabilité de l’application.

Historique

The Grinder, « Le moulin », a été initialement développé pour les besoins du livre J2EE Performance Testing with BEA WebLogic Server par Paco Gómez et Peter Zadrozny.

Par la suite, Philip Aston a pris possession du code et l’a retravaillé pour en créer The Grinder 2.

C’est en Juillet 2003 que la première édition du livre fut publiée par Peter, Philippe et Ted Osborne, faisant ainsi un usage intensif de l’outil à sa deuxième version (The Grinder 2).

Peu après, Philip Aston commence à travailler sur The Grinder 3. Cette version offre de nombreuses nouvelles fonctionnalités, la plus importante est le Scripting Jython.

Environnement de développement

• Eclipse 3.6.
• Apatana 3/Pydev : plugin eclipse pour le développement de projets python :
  • Update Site : http://download.aptana.com/studio3/plugin/install
• Grinder Stone : plugin eclipse pour exécuter les scripts grinder. Il permet également de lancer des sessions de debugging.
  • Update Site : http://grinderstone.googlecode.com/svn/update/site.xml
• Jython 2.2.1
• Grinder 3.4

Architecture & Conception des Scripts

Architecture

Il est important de comprendre l’architecture du framework,  ses différents composants et son mode fonctionnement.

Afin d’illustrer ce propos, je vous propose les deux schémas ci-dessous ;  l’un qui fait apparaitre les composants de base d’une plateforme d’injection d’un point de vue conceptuel, et l’autre illustrant l’architecture et les terminologies spécifiques à The Grinder.

Design View

The Grinder View

• La console contrôle les workers (les injecteurs) par le biais des agents et se charge d’agréger les résultats de test de l’ensemble des injecteurs de tous les agents.
• Les agents sont en charge de piloter un ou plusieurs worker (généralement une instance « agent » est créé par JVM).
• Les workers (grinder.processes) permettent d’injecter la charge au système à tester en démarrant le nombre de thread spécifié par la clé « grinder.threads » (les utilisateurs virtuels) et remontent les statistiques à la console. Chaque thread ainsi créé, exécute le script de test « grinder.runs » fois.

Conception des scripts et des scénarios

Le diagramme ci-dessous permet d’illustrer la séquence d’exécution d’un script grinder (gérée par le framework) couplée avec celle d’un scénario composé de deux tâches (gérée par le développeur) :

Généralement les scénarios fonctionnels à dérouler se différencient  en bout de chaîne, ou plus simplement dit, partagent un certain  nombre de transactions (Tâches) ; Ce qui fait apparaître le besoin de décomposer vos scénarios en un ensemble de tâches réutilisables.

Le lien entre deux tâches successives (récupérer l’output d’une tâche pour le faire passer en input de la tâche suivante) est réalisé par la requête suivante:

HTTPPluginControl.getHTTPUtilities().getLastResponse()

Un scénario est donc défini par la succession d’un ensemble de tâches. Il encapsule la logique d’exécution de ses tâches (Scenario.run()).

Un « ScenarioAScript » permet la création et l’initialisation d’un « Scenario » composé de deux tâches « Task1 » et « Task2 ». Il est également responsable de la gestion de la rampe pour son scénario se traduisant généralement par une attente d’une durée égale au « pacingTime » (le temps d’attente entre le lancement de la première exécution de deux Threads successifs).

Un « Tir » constitue le script d’entrée pour The Grinder, il joue le rôle d’un orchestrateur et permet de répartir les threads sur l’ensemble des scénarios (affectation Thread / ScenarioXScript) selon la configuration souhaitée.

L’exemple ci-dessous permet de répartir les threads sur 3 scénarios avec les proportions suivantes : le  ScenarioAScript 50%, le ScenarioBScript 25 % et le ScenarioCScript 25 %

from net.grinder.script.Grinder import grinder
scripts = ["ScenarioAScript", "ScenarioBScript", "ScenarioCScript"]
# Ensure modules are initialised in the process thread.
for script in scripts: exec("import %s" % script)
def createTestRunner(script):
    exec("x = %s.TestRunner()" % script)
    return x
class TestRunner:
    def __init__(self):
        tid = grinder.threadNumber
        if tid % 4 == 2:
            self.testRunner = createTestRunner(scripts[1])
        elif tid % 4 == 3:
            self.testRunner = createTestRunner(scripts[2])
        else:
            self.testRunner = createTestRunner(scripts[0])
    # This method is called for every run.
    def __call__(self):
        self.testRunner()

Ce qu’il faut savoir

Réinitialisation des cookies au lancement de chaque run

Il faut savoir qu’à chaque run, The Grinder effectue un « cookie-reset » ; ce qui pourrait être très embêtant dans le cas où votre démarche de test s’inscrit dans la logique suivante:

• S’authentifier (création de la session, initialisation des cookies)
• Boucler sur le scénario fonctionnel n fois
• Se déconnecter

Pour pallier ce problème, la solution la plus simple consiste à récupérer l’ensemble des cookies initialisés au démarrage de la session lors du premier run et les injecter par la suite dans les runs qui suivent comme suit :

# récupérer l’objet HTTPClientContext pour le thread en cours au premier run.
threadContext = HTTPPluginControl.getThreadHTTPClientContext()
#récupération de l’ensemble des cookies au premier run
cookies=CookieModule.listAllCookies(threadContext)
      # récupérer l’objet HTTPClientContext pour le thread en cours.
      threadContext = HTTPPluginControl.getThreadHTTPClientContext()
      # Injection des cookies dans le header http du thread en cours
      for cookie in cookies:
          CookieModule.addCookie(cookie, threadContext)

Une deuxième solution est envisageable ; Il s’agit de désactiver la gestion automatique des cookies :

HTTPPluginControl.getConnectionDefaults().useCookies = 0

et de créer son propre « handler » de cookie :

# un « implements » à la python de l’interface «CookiePolicyHandler»
class MyCookiePolicyHandler(CookiePolicyHandler):
    # implement your own cookie acceptance policy.
    def acceptCookie(self, cookie, request, response):
        # traitement souhaité
        return 1
    # control the sending of cookies according to the matching rules
    # for the path, domain, protocol, etc
    def sendCookie(self, cookie, request):
        # traitement souhaité
        return 1

Par la suite, quelque part dans vos scripts, vous devrez faire un « set » du custom-handler :

CookieModule.setCookiePolicyHandler(MyCookiePolicyHandler())

Http/GET non implicite des ressources statiques

Les requêtes http exécutées par le framework ne permettent pas de récupérer systématiquement les ressources statiques (cacheables par défaut) liées à la page demandée, comme les fichiers de type *.css, *.jpeg, *.gif, *.jar,… Il faut donc penser à les récupérer explicitement (par un http/GET du fichier en question) dans le cas où vous jugerez que cela pourrait avoir un impact sur les résultats de test.

Gestion des « runs »

A un certain moment, lors du développent de vos scripts,  vous auriez été tentés de gérer le nombre d’exécutions (grinder.runs) par vous-mêmes afin de contourner certains problèmes, notamment celui du cookie-reset précédemment évoqué. Je comprendrais que vous eussiez été plus à l’aise avec un « loop » et des « if » pour implémenter toute la logique d’exécution souhaitée, mais vous auriez sans doute constaté que les temps de réponse augmentaient d’une manière aberrante et proportionnelle au nombre de VUs (grinder.threads) ; ce qui est certainement lié à la contention des ressources et des threads dans vos « loop ». Je voulais donc en venir à la règle suivante: « Déléguer au framework ce qu’il a à faire reste un principe fondamental de son utilisation à ne pas négliger ».

Externalisation et centralisation de la configuration au niveau de grinder.properties

Mettre toute la configuration de vos scripts dans le fichier grinder.properties vous permettra de regrouper l’ensemble des paramètres d’une manière centralisée: «  un seul fichier à maintenir ». Vous disposez nativement de la méthode «  grinder.getProperties ()«clé» pour récupérer les valeurs des différentes clés (pas besoin d’une classe utilitaire avec un java.util.Properties.load()).

Gestion des exceptions

N’hésitez pas à renforcer vos tests par des blocs de try / catch afin de passer le test précédemment exécuté ou encore celui qui est en cours d’exécution en « fail ».

Il faudra également distinguer les erreurs techniques liées au traitement de la requête par le serveur (serveur injoignable, http code = ! 200,…) des erreurs fonctionnelles liées à la logique du déroulement du scénario (jeu de données invalide, des inputs introuvables, rendu de la page incohérent,…).

Ci-dessous une manière de faire:

import sys, traceback
request = Test(1, "Basic request").wrap(HTTPRequest(url = "http://localhost:7001"))
     try:
        result = request.GET("index.html")
     except:
        # mark the test as a failure
        grinder.statistics.forLastTest.success = 0
        # tracer l’erreur d’origine:
        grinder.getLogger().error("Unexpected error: %s: %s: %s" % (sys.exc_info()[0], sys.exc_info()[1], traceback.print_exc()))
        # throw new ExceptionTechnique
        raise ExceptionTechnique(« message d’erreur »)
     # Si le traitement dans le bloc try est exécuté
     # correctement, on vérifie que le status du dernier test est
     # OK, et que le code retour http == 200
     else:
        # récupérer l’objet Statistique pour le dernier test
        statisticsForTest = grinder.statistics.forLastTest
        # Si le test s’est terminé avec succès  et
        # http reponse code == 200
        if statisticsForTest.success and
           statisticsForTest.getLong("httpplugin.responseStatus")
           == 200:
            try:
               Dérouler votre checkList sur le rendu attendu
            except:
               # mark the test as a failure
               grinder.statistics.forLastTest.success = 0
               # tracer l’erreur d’origine:
               grinder.getLogger().error("Unexpected error: %s: %s: %s" % (sys.exc_info()[0], sys.exc_info()[1], traceback.print_exc()))
               # throw new ExceptionFocntionnelle :
               raise ExceptionFonctionnelle(« message d’erreur »)
        # sinon : erreur lors du traitement de la requête
        else:
            # mark the test as a failure
            grinder.statistics.forLastTest.success = 0
            # throw new ExceptionTechnique
            raise ExceptionTechnique(« message d’erreur »)

Parsing XML et XPath:

Le parsing xml de la réponse constitue une étape quasi-évidente pour dérouler votre check-list sur les éléments attendus et également pour récupérer les valeurs de certains d’entre eux ; ainsi, vous pourrez savoir s’il est possible de passer à l’étape suivante de votre scénario.

En terme de technologie adoptée, je vous laisse faire votre choix entre l’utilisation des APIs standards fournies avec le JDK (javax.xml.parsers, org.xml.sax, javax.xml.xpath) et l’API vtd-xml qui est plus puissante et moins consommatrice (basée sur la technique Virtual Token Descriptor (VTD))

Accès concurrents aux ressources « statiques »

Si vous manipulez des variables statiques dans vos scripts python, vous êtes sûrement face à un problème d’accès concurrentiel du moment que vous avez plus d’un injecteur sur une même JVM (grinder.processes>1).

On reconnaît ce cas de figure par le positionnement du mot clé « global » sur une variable précédemment déclarée dans le script, dans le but de pourvoir modifier sa valeur (accès en écriture) à l’intérieur d’une méthode :

maVariable = 0
   def incrementMaVariable() :
      global maVariable
      maVariable += 1

Pour remédier à ce problème, la solution la plus évidente consiste clairement à éviter d’employer ce genre de pratique qui n’est pas en phase avec l’architecture distribuée de The Grinder.
Néanmoins si vous y tenez, il est possible d’utiliser la classe Lock du module threading.py:

import threading
# récupérer un 	Object Lock pour la gestion d'accès concurrent à la ressource " maVariable "
lock = threading.Lock()
maVariable = 0
    def incrementMaVariable() :
       try:
           # will block if lock is already held
           lock.acquire()
           # lecture de la variable
           global maVariable
           # écriture de la variable
           maVariable += 1
       finally:
           # release lock
           lock.release()

Nommage des transactions et unicité des identifiants de test

Pensez à nommer vos transactions d’une manière homogène et ordonnée ; cela vous facilitera la lecture des résultats de test par la suite.
Le modèle suivant pourrait apporter un certain confort de lisibilité et de clarté : SC-<Référence du scénario>-STEP-<Numéro de la transaction>)<Libellé de la transaction>

Prenons par exemple le scénario « consultation du profil », composé de trois transactions à savoir : login, consulter profil et logout.
Cela aurait donné quelque chose de ce genre lors de la définition des tests:

request1 = Test(1, "SC-CONSULTATION-PROFIL-STEP-1)Login")
request2 = Test(2, "SC-CONSULTATION-PROFIL-STEP-2)Consultation du profil")
request3 = Test(3, "SC-CONSULTATION-PROFIL-STEP-3)Logout")

Les identifiants de vos tests doivent être uniques dans un scope «grinder-project» ; cela vous permettra d’une part d’établir rapidement le lien entre le test id et son libellé, et d’autre part d’éviter toute confusion de transaction (un même identifiant pour deux transactions différentes, bien qu’il soit toujours possible de les distinguer par le libellé).

N’optez pas pour des variables statiques (avec un système d’incrémentation), vous risquez de vous replonger dans le problème d’accès concurrents à partir du moment où vous êtes dans le cas d’une configuration multi-process par JVM; à la limite gardez-les en dur.

Intégration dans le Build PipeLine

Il existe un plugin Hudson : http://wiki.hudson-ci.org/display/HUDSON/Grinder+Plugin:

Ce plugin permet d’exécuter les scripts « grinder » pendant le build et d’inclure les résultats de tests obtenus dans le rapport hudson.

Génération des rapports graphiques

Il existe principalement deux outils :

• Grinder Analyzer : Permet de parser les logs grinder et de générer des rapports graphiques (au format html). L’utilisation de cet outil reste très simple et suffisante  pour un aperçu visuel des résultats lorsqu’il s’agit d’un environnement de test mono-agent et mono-worker. Cependant, il trouve rapidement ses limites face à des données  issues de plusieurs « agents » et « workers », ou également lorsqu’il s’agit de générer des graphiques de comparaison entre deux tests.
  • Démo: http://track.sourceforge.net/example/report.html
• ground-report : Produit un ensemble de rapports graphiques (rapport de synthèse, rapport individuel par test, rapport de comparaison entre plusieurs tests,…) au format pdf et à partir d’une base de données PostgreSQL. Il est également possible de produire des rapports au format rtf, xml  ou xhtml.
  • Démo: http://ground.sourceforge.net/samples.html
  • Il se distingue par :
    • La qualité de ses rapports.
    • Configuration rapide.
    • La sauvegarde des résultats de test en base de données garantissant ainsi d’avoir l’historique de l’ensemble tests.
    • Son « ToolKit » pour les opérations d’injection des données « grinder » en base.

Les limites

• Ne produit pas nativement des graphiques.
• Ne permet pas de simuler des sessions à partir d’adresses IP différentes, ce qui constitue  généralement un point très important lorsque le target system  est « load-balancé » (souvent le cas en production).
• Manque du support.

Conclusion

Dans la mesure où les tests de performance s’imposent de plus en plus, comme c’est le cas actuellement pour les tests unitaires, les tests d’intégration et les tests fonctionnels qui ne cessent de se greffer dans nos projets, il me semble envisageable de compléter la stack de test en faisant d’eux une partie intégrante des projets; ce qui nous permettra de les faire constamment marier aux évolutions que subissent les applications.

Aujourd’hui on parle d’un test unitaire cassé, on pourrait bien parler d’un script de test de charge cassé.

Pour peu que l’on ait conçu et développé ses scripts proprement (sans pour autant frôler la limite de l’over-design), on gagne énormément en maintenabilité: modifier le comportement d’un script, c’est comme si l’on s’apprêtait à modifier une  méthode d’un service.

Le fait que The Grinder s’appuie sur du Jython (implémentation de Python en Java),  on garde toujours un même environnement d’exécution; que ce soit du .java  vers du .class ou du .py vers $py.class jusqu’au runtime, c’est toujours la JVM qui bosse. En plus, vous continuez à profiter de toutes les API Java; ce qui vous offre le moyen de rester dans vos habitudes et de ne pas forcément glisser dans une démarche full-python.

Nous verrons dans cet article qu’il est possible de développer des tests automatisés capables de s’adapter facilement aux contraintes d’asynchronismes et de se passer d’un blocage à temps constant grâce à l’API Awaitility.

Awaitility est une API open source créée en juillet 2010 pour répondre aux problématiques de tests de systèmes asynchrones. Utilisable sous forme de DSL, elle permet de simplifier les opérations qui nécessitaient auparavant la gestion de Threads, de Time Out et de concurrence d’accès. Awaitility est disponible aussi bien pour Java que pour Groovy et Scala. Le projet est actuellement dans sa version 1.3.1 et a été utilisé dans notre mission pour valider le comportement de deux serveurs qui communiquaient entre eux.

Si vous utilisez Maven, vous pouvez ajouter la dépendance suivante dans votre pom.xml

<dependency>
    <groupId>com.jayway.awaitility</groupId>
    <artifactId>awaitility</artifactId>
    <version>1.3.1</version>
    <scope>test</scope>
</dependency>

Un exemple de test

Imaginons un service chargé de publier des annonces sur des panneaux publicitaires.

Vous êtes un annonceur et vous souhaitez publier une annonce sur l’ensemble des panneaux publicitaires d’un réseau. Un service est mis à votre disposition, voici l’interface :

public interface IServicePanneauxPublicitaires {
    /**
     * Propage l'annonce sur tous les panneaux publicitaires La propagation peut durer jusqu'à une minute.
     * Note : Cet appel est non-bloquant
     * @param annonce
     *            Annonce à afficher sur les panneaux publicitaires
     */
    void publierAnnonce(String annonce);
    /**
     * @return Retourne la liste des panneaux publicitaires
     */
    List<PanneauPublicitaire> getPanneauxPublicitaires();
}

Comme on peut le remarquer, lorsque l’utilisateur de ce service va demander la publication de son annonce, il n’est pas assuré qu’elle sera immédiatement affichée sur l’ensemble du parc de panneaux publicitaires.

Si on désire tester que les panneaux affichent bien l’annonce en question, il faut être capable de laisser une minute (au maximum !) au service pour qu’il puisse faire son travail.

Le test ci-dessous montre comment tirer partie des possibilités d’Awaitility pour construire notre test d’intégration.

@Test
/**
 * Scenario de test :
 * - publier une annonce via le service IServicePanneauxPublicitaires
 * - vérifier pour chacun des panneaux que l'annonce est publiée
 * - contrainte temporelle : la propagation doit durer moins d'une minute
 */
public void should_propagate_annonce_to_all_panneaux_publicitaires_within_one_minute() throws Exception {
    // récupération d'une implémentation du service de gestion des panneaux publicitaires
    IServicePanneauxPublicitaires servicePanneauxPublicitaires = new ServicePanneauxPublicitaires();
    // Publication d'une annonce
    // Rend la main à la méthode appelante mais peut mettre jusqu'à
    // une minute pour publier l'annonce sur tous les panneaux
    servicePanneauxPublicitaires.publierAnnonce("Fin des soldes dans 2 jours!");
    // Vérification de la publication de l'annonce sur les panneaux
    Callable<Boolean> condition = isAnnoncePropageeSurTousLesPanneaux(servicePanneauxPublicitaires, "Fin des soldes dans 2 jours!");
    Awaitility.await().atMost(Duration.ONE_MINUTE).until(condition);
}

Intéressons nous tout d’abord à la dernière ligne car c’est elle qui porte toute la logique du test.

Awaitility.await().atMost(Duration.ONE_MINUTE).until(condition);

En français elle signifie : La condition doit être vérifiée (return true) en moins d’une minute, sinon le test échoue.

La condition en question est un Callable<Boolean> qui contient les éléments de test à valider :

private Callable<Boolean> isAnnoncePropageeSurTousLesPanneaux(final IServicePanneauxPublicitaires servicePanneauxPublicitaires, final String annonce) {
    return new Callable<Boolean>() {
        public Boolean call() throws Exception {
            // pour chaque panneau publicitaire
            List<PanneauPublicitaire> panneauxPublicitaires = servicePanneauxPublicitaires.getPanneauxPublicitaires();
            for (PanneauPublicitaire panneauPublicitaire : panneauxPublicitaires) {
                // on vérifie que l'annonce a été publiée
                String annonceCourante = panneauPublicitaire.getAnnonce();
                if (!annonce.equals(annonceCourante)) {
                    return false;
                }
            }
            // l'annonce a été propagée sur tous les tableaux
            return true;
        }
    };
}

L’algorithme est simple, pour que le test soit valide, il faut que l’annonce de chaque panneau publicitaire soit égale à l’annonce passée en paramètre. Si au moins un des panneaux n’a pas la bonne annonce, on retourne false. Si tous les panneaux ont la bonne annonce, on retourne true.

Fonctionnement d’Awaitility

Comment se déroule l’exécution du test should_propagate_annonce_to_all_panneaux_publicitaires_within_one_minute ? Awaitility appelle en boucle la méthode isAnnoncePropageeSurTousLesPanneaux() tant que celle-ci retourne false ou que le délai maximum fixé à une minute n’est pas atteint.

L’intérêt d’Awaitility réside dans sa capacité à continuer l’exécution du test dès que la condition est vérifiée. Dans notre cas, si tous les panneaux publicitaires ont été mis à jour en 5 secondes, il n’est pas nécessaire de bloquer le test pendant 1 minute. Par contre, dans le pire des cas, il faudra attendre le time out avant que le test passe en échec.

Mais attention, quand on dit « Awaitility appelle en boucle », il faut comprendre que le callable sera exécuté toutes les 100 ms (valeur par défaut). Cette valeur est modifiable et il est conseillé de la changer si nous ne voulons pas stresser les systèmes à tester.

On désire par exemple appeler le service qu’une fois par seconde, c’est ce qu’Awaitility appelle le pollInterval. On peut fixer le pollInterval pour l’ensemble des tests :

Awaitility.setDefaultPollInterval(Duration.ONE_SECOND);
Awaitility.await().atMost(Duration.ONE_MINUTE).until(condition);

Ou simplement pour le test en cours :

Awaitility.await().atMost(Duration.ONE_MINUTE).pollInterval(Duration.ONE_SECOND).until(condition);

De la même manière, on peut modifier le temps d’attente avant que la condition de test soit exécutée pour la première fois. Dans notre cas, on peut laisser 5 secondes d’avance au service de propagation des annonces avant de commencer à l’interroger.

Awaitility.await().atMost(Duration.ONE_MINUTE).pollDelay(Duration.FIVE_SECONDS).until(condition);

Awaitility permet d’associer tous ces paramètres grâce aux méthodes and() et with(). Voici l’exemple complet (pollInterval + pollDelay) en utilisant les imports statiques pour faciliter la lisibilité :

await().atMost(ONE_MINUTE).pollInterval(ONE_HUNDRED_MILLISECONDS).with().pollDelay(TWO_SECONDS).until(condition);

La condition à valider sera vérifiée au bout de 2 secondes et ensuite toutes les 100 millisecondes.

Durée et Unité de temps

Comme nous l’avons vu, Awaitility propose quelques paramètres de temps bien pratiques, voici la liste exhaustive des Duration que vous pouvez utiliser en paramètre de la méthode public ConditionFactory atMost(Duration timeout) :

Vous pouvez bien sûr configurer plus finement le timeout en utilisant la méthode public ConditionFactory atMost(long timeout, TimeUnit unit). Pour rappel, les valeurs de java.util.concurrent.TimeUnit sont :

Voici un exemple d’utilisation du TimeUnit pour une configuration plus fine des time outs.

// attendre au maximum 3 minutes
await().atMost(3, MINUTES).until(condition);

Conclusion

Les possibilités d’Awaitility ne s’arrêtent pas là et vous trouverez de plus amples informations en consultant le site officiel et la Javadoc qui contient des exemples complets.

Selenium regroupe une suite d’outils permettant de tester des applications web. Tout comme les tests unitaires, Selenium permet notamment de vérifier la non-régression d’une application et est un gage de qualité supplémentaire. Bien que la création des tests Selenium soit relativement simple, automatiser leur exécution sur un serveur d’intégration continue reste complexe à mettre en œuvre. Je vous propose une solution avec l’outil de build Maven. Disposant de nombreux plugins, comme SQL, Failsafe, Jetty et Selenium, Maven permet la mise en place d’une automatisation satisfaisante. Cette solution peut servir aussi aux tests d’intégration.

Selenium, un puissant outil pour créer des tests fonctionnels

Les tests Selenium reproduisent toutes sortes d’interactions qu’un utilisateur peut effectuer sur un navigateur web. Un test Selenium est constitué d’un script pouvant être écrit dans plusieurs langages (Java, Html, C#, Groovy, Php, etc.). Ce script est ensuite interprété par le serveur Selenium RC, qui s’occupe d’envoyer les bonnes commandes au navigateur. Les avantages de Selenium sont d’être compatible avec de nombreux navigateurs (Internet Explorer, Firefox, Chrome, etc.) et d’offrir un outil de création de test, appelé Selenium IDE. Ce dernier est disponible sous forme d’un plugin Firefox. Les scripts Selenium sont relativement simples à coder directement, puisqu’il s’agit à chaque fois d’indiquer le type d’interaction (clic, saisie, etc.), puis de sélectionner l’élément en jeu (lien, tableau, div, input, etc.), et enfin d’indiquer une éventuelle valeur. Cependant, on aurait souhaité la disponibilité de Selenium IDE sur d’autres navigateurs.

Vers une automatisation des tests Selenium avec Maven

L’exécution automatique des tests unitaires sur un serveur d’intégration continue est une pratique très répandue. En utilisant une base de données en mémoire, comme HSQLDB, les tests unitaires peuvent être exécutés facilement quel que soit l’environnement. De la même manière, il est intéressant de pouvoir lancer automatiquement ces tests fonctionnels sur un serveur d’intégration. Cependant, la mise en place est plus complexe: à chaque exécution, il faut au préalable s’assurer que la base de données soit dans un état cohérent (en terme de jeu de données), mais aussi que les serveurs web et Selenium RC soient démarrés.

Voici les étapes que nous allons automatiser à l’aide de l’outil Maven :

1. Initialiser la base de données avec un jeu de données : Plugin maven SQL.
2. Construire l’application web et la déployer sur un serveur web Jetty : Plugin maven Jetty.
3. Démarrer le serveur Selenium RC : Plugin maven Selenium
4. Exécuter les tests Selenium : Plugin maven Failsafe.

Comme vous pouvez le constater, cette solution repose sur l’outil de build Maven et le serveur web Jetty. Dans un précédent article, j’avais proposé une autre solution basée sur l’outil Ant. Avant d’aller plus loin, il est important de connaître le cycle de vie du build de Maven. Voici l’ordre d’exécution des principales phases du build :

• validate
• compile
• package
• test
• pre-integration-test
• integration-test
• post-integration-test
• verify
• install
• deploy

Lorsqu’on lance une phase, toutes les phases qui la précèdent sont exécutées au préalable. La phase test exécute les tests unitaires. Il existe aussi une phase integration-test qui va nous servir à exécuter les tests Selenium. Cette phase est précédée de la phase pre-integration-test et suivie de la phase post-integration-test qui vont respectivement nous aider à préparer puis nettoyer l’environnement d’exécution : démarrage et arrêt des serveurs Web et Selenium RC typiquement. Pour lancer les tests Selenium, il est nécessaire de lancer la commande mvn verify et non mvn integration-test, sinon la phase post-integration-test ne sera pas exécutée.

Je vais maintenant aborder l’intégration de chacune des briques (Selenium, base de données, et serveur web) dans Maven.

Intégration de Selenium dans Maven

L’intégration de Selenium dans Maven se décompose en deux étapes :

• Déclarer l’exécution des tests Selenium via le plugin Failsafe.
• Démarrer le serveur Selenium RC en pre-integration-test et l’arrêter en post-integration-test.

Solution 1: Exécuter les tests avec le plugin Surefire

Pour intégrer l’exécution des tests Selenium, il existe une première solution basée sur le plugin Surefire. La fonction première de ce plugin est d’exécuter les tests unitaires lors de la phase test et de générer un rapport. L’idée ici est de considérer les tests Selenium, comme des tests unitaires JUnit. Pour inclure les tests Selenium, il faut définir un plan d’exécution surefire-integration-test associé à la phase integration-test en incluant dedans les classes de test Selenium. Par ailleurs, il faut exclure les tests Selenium de la phase test (dans <configuration>). On obtient alors la déclaration du plugin suivant dans le pom :

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <configuration>
      <includes>
         <!-- Inclure les tests unitaires ici ... -->
      </includes>
      <excludes>
         <exclude>com/xebia/selenium/**/*Test.java</exclude>  <!-- Exclure les tests Selenium ici ... -->
      </excludes>
   </configuration>
   <executions>
      <execution>
         <id>surefire-integration-test</id>
         <phase>integration-test</phase>
         <goals>
            <goal>test</goal> <!-- La phase integration-test va lancer les tests... -->
         </goals>
         <configuration>
            <skip>false</skip>
            <includes>
               <include>com/xebia/selenium/**/*Test.java</include> <!-- ... Inclure les tests Selenium ici -->
            </includes>
         </configuration>
      </execution>
   </executions>
</plugin>

La solution Surefire n’est cependant pas optimale. En effet, Surefire a été conçu à l’origine uniquement pour les tests unitaires. Ce qui explique que si un test échoue, le build maven s’arrêtera à la phase integration-test, sans aller jusqu’au post-integration-test. Du coup, l’environnement d’exécution ne sera pas correctement nettoyé.

Solution 2 recommandée: Exécuter les tests avec le plugin FailSafe

Pour corriger les limitations de Surefire, un nouveau plugin FailSafe dédié aux tests d’intégration a été créé. Ce plugin est un fork de Surefire, qui ne bloque pas le cycle de vie du build en cas d’échec. En lançant les tests Selenium avec mvn verify et non mvn integration-test, on s’assure que la phase post-integration-test sera bien exécutée en cas d’erreurs. Le rôle de la phase verify est donc clairement de vérifier l’état d’exécution des tests d’intégration. Voici comment déclarer le plugin FailSafe dans le pom :

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-failsafe-plugin</artifactId>
   <version>2.7.2</version>
   <configuration>
      <reportsDirectory>${basedir}/target/surefire-reports</reportsDirectory>
      <includes>
         <include>com/xebia/selenium/**/*.java</include> <!-- ... inclure les tests Selenium -->
      </includes>
      <systemPropertyVariables>
         <jetty.port>${jetty.port}</jetty.port>
         <jetty.context>${artifactId}</jetty.context>
      </systemPropertyVariables>
   </configuration>
   <executions>
      <execution>
         <id>integration-test</id>
         <goals>
            <goal>integration-test</goal>
         </goals>
      </execution>
      <execution>
         <id>verify</id>
         <goals>
            <goal>verify</goal>
         </goals>
      </execution>
   </executions>
</plugin>

Afin de rendre paramétrable certaines valeurs de contexte dans vos classes de tests Selenium, comme le port et le contexte de l’application, il est possible d’indiquer des propriétés systèmes dans le plugin FailSafe. Pour cela, il suffit d’ajouter l’élément <systemPropertyVariables> dans <configuration> avec les différentes propriétés.
On remarque aussi la propriété <reportsDirectory> qui permet de générer les rapports de tests dans le même dossier que Surefire. Le serveur d’intégration inclura ainsi les résultats des tests Selenium avec ceux des tests unitaires. Une autre solution est de définir l’emplacement des rapports directement sur le serveur d’intégration continue. Par défaut, FailSafe place les rapports dans basedir/target/failsafe-reports.

Ajout du plugin Selenium (Pour démarrer et arrêter le serveur Selenium RC)

Afin de lancer automatiquement le serveur Selenium RC pendant l’exécution de la phase integration-test, il faut ajouter le plugin suivant dans le pom :

<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>selenium-maven-plugin</artifactId>
   <version>1.0.1</version>
   <executions>
      <execution>
         <id>start</id>
         <phase>pre-integration-test</phase>
         <goals>
            <goal>start-server</goal>
         </goals>
         <configuration>
            <background>true</background>
         </configuration>
      </execution>
      <execution>
         <id>stop</id>
         <phase>post-integration-test</phase>
         <goals>
            <goal>stop-server</goal>
         </goals>
      </execution>
   </executions>
</plugin>

L’option <background>true</background> permet de ne pas bloquer le processus Maven pendant que le serveur Selenium RC est démarré.

Configuration du serveur web avec le plugin Jetty

Préalablement à l’exécution des tests Selenium, il est nécessaire de démarrer l’application sur un serveur web durant la phase pre-integration-test. Le serveur sera arrêté durant la phase post-integration-test. Voici la manière de déclarer le plugin Jetty dans le pom :

<plugin>
   <groupId>org.mortbay.jetty</groupId>
   <artifactId>maven-jetty-plugin</artifactId>
   <version>6.1.10</version>
   <configuration>
      <scanIntervalSeconds>10</scanIntervalSeconds>
      <stopKey>foo</stopKey>
      <stopPort>9999</stopPort>
      <webAppSourceDirectory>${webapp.dir}</webAppSourceDirectory>
      <connectors>
         <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
            <port>${jetty.port}</port>
            <maxIdleTime>60000</maxIdleTime>
         </connector>
      </connectors>
   </configuration>
   <executions>
      <execution>
         <id>start-jetty</id>
         <phase>pre-integration-test</phase>
         <goals>
            <goal>run</goal>
         </goals>
         <configuration>
            <scanIntervalSeconds>0</scanIntervalSeconds>
            <daemon>true</daemon>
         </configuration>
      </execution>
      <execution>
         <id>stop-jetty</id>
         <phase>post-integration-test</phase>
         <goals>
            <goal>stop</goal>
         </goals>
      </execution>
   </executions>
</plugin>

L’attribut <webAppSourceDirectory> permet d’indiquer le chemin de l’application web. On peut aussi remarquer l’utilisation d’une propriété jetty.port pour mettre en paramètre le port d’écoute de Jetty. Celle-ci se déclare de la manière suivante dans le pom.xml :

<properties>
   <jetty.port>9090</jetty.port>
   ......
</properties>

Manipulation de la base de données

Il existe de nombreuses solutions pour préparer la base de données aux tests d’intégration. Même s’il est possible d’utiliser une base de données en mémoire, comme HSQLDB, je recommanderais plutôt d’utiliser le même type de base qu’en production, parce que nous exécutons des tests end-to-end. Pour insérer les jeux de données, il est possible d’utiliser deux plugins Maven : SQL ou DbUnit. J’ai privilégié l’utilisation du plugin SQL, car mes scripts étaient déjà écrits en SQL. En effet, DbUnit utilise son propre format en XML.
Le plugin SQL permet aussi d’exécuter des procédures stockées et des fonctions en changeant le type de délimiteur, qui est par défaut ‘;’. Dans <configuration>, on définit le driver, ainsi que les paramètres de connexion. J’ai ajouté une dépendance au driver d’Oracle dans mon exemple. Le paramètre <autocommit> permet d’indiquer si l’on veut que les scripts soient exécutés de manière transactionnelle ou non.
Ensuite, il suffit de déclarer un plan d’exécution ‘insert_data’ pour la phase pre-integration-test et un autre ‘drop_data’ pour la phase post-integration-test en indiquant les scripts SQL.

<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>sql-maven-plugin</artifactId>
   <version>1.4</version>
   <dependencies>
      <dependency>
         <groupId>com.oracle</groupId>
         <artifactId>ojdbc14</artifactId>
         <version>10.2.0.4</version>
      </dependency>
   </dependencies>
   <configuration>
      <driver>oracle.jdbc.driver.OracleDriver</driver>
      <url>jdbc:oracle:thin:@localhost:1521:capitaineHadoc</url>
      <username>tintin</username>
      <password>milou</password>
      <delimiter>;</delimiter>
      <delimiterType>normal</delimiterType>
      <keepFormat>true</keepFormat>
      <skip>${maven.test.skip}</skip>
      <autocommit>true</autocommit>
   </configuration>
   <executions>
      <execution>
         <id>insert-data</id>
         <phase>pre-integration-test</phase>
         <goals>
            <goal>execute</goal>
         </goals>
         <configuration>
            <orderFile>ascending</orderFile>
            <fileset>
               <basedir>${basedir}/path/to/sql/files</basedir>
               <includes>
                  <include>insert-data.sql</include>
               </includes>
            </fileset>
         </configuration>
      </execution>
      <execution>
         <id>drop-data</id>
         <phase>post-integration-test</phase>
         <goals>
            <goal>execute</goal>
         </goals>
         <configuration>
            <orderFile>ascending</orderFile>
            <fileset>
               <basedir>${basedir}/path/to/sql/files</basedir>
               <includes>
                  <include>drop-data.sql</include>
               </includes>
            </fileset>
         </configuration>
      </execution>
   </executions>
</plugin>

Execution des tests Selenium

Depuis Maven

Après avoir déclaré tous les plugins dans le pom.xml, il suffit de lancer la commande suivante :

mvn verify

Voici alors une synthèse des logs que l’ont obtient :

[INFO] [selenium:start-server {execution: start}]
[INFO] 1
[INFO] [jetty:run {execution: start-jetty}]
[INFO] [failsafe:integration-test {execution: integration-test}]
[INFO] [selenium:stop-server {execution: stop}]
[INFO] 1
[INFO] [jetty:stop {execution: stop-jetty}]
[INFO] [failsafe:verify {execution: verify}]
[INFO] Failsafe report directory: D:Javasoftworkspacepid-trunktargetsurefire-reports

Depuis votre IDE

Lorsqu’on développe de nouveaux tests Selenium ou tout simplement pour débugger, il est nécessaire de les exécuter sur son IDE. Pour parvenir à cela, il suffit de lancer les commandes suivantes (dans des terminaux différents) :

1. Préparer la base de données si nécessaire :

   mvn sql:execute

2. Démarrer le serveur Selenium RC :

   mvn selenium:start-server

3. Démarrer le serveur web Jetty :

   mvn jetty:run

4. Exécuter le test depuis votre IDE.

Conclusion

Avec ses nombreux plugins, Maven est un puissant outil pour automatiser l’exécution des tests Selenium. Les solutions proposées dans cet article peuvent servir de manière générale aux tests d’intégration. Les prochaines versions de Maven ne prévoient pas une séparation des sources entre les tests unitaires et les tests d’integration (src/main/test vs src/main/it). En effet, le plugin FailSafe permet de gérer les tests d’intégration de manière dédiée.

Avec un peu de retard sur les autres, voici le cinquième article de cette série sur Grails. Nous allons parler ici de :

• Tests unitaires
• Tests d’intégration
• Mesures de qualité de code
• Intégration continue

En appliquant le tout à notre projet test bien aimé : NoThunes.

Tout code sera testé, sinon par vous, alors par vos utilisateurs …

La nécessité de tester notre code, quel qu’il soit, a été largement décrite, soutenue et argumentée. Par conséquent, nous ne reviendrons pas dessus dans cet article. Je tiens à m’excuser pour avoir placé en dernier lieu l’activité qui devrait ouvrir le bal dans la rédaction d’une application (le TDD c’est bon, mangez-en). Cela m’a paru plus attractif de mettre les mains dans le cambouis de suite. Mais maintenant nous allons passer aux choses sérieuses : les Tests.

Scott Davis, sur le blog d’IBM, a rédigé une série d’articles Mastering Grails dont 2 nous concernent plus particulièrement ici :

• Mock Testing with Grails
• Testing your Grails application

Les tests à la mode Grails sont largement bien décrits dans ces 2 articles. Je vais donc vous fournir ici mon retour d’expérience sur l’application en conditions réelles de ces conseils. Les tests unitaires au sens propre sont très bien décrits dans ces 2 articles, nous allons donc directement sauter aux tests d’intégration.

Tests d’intégration Grails dans la pratique

Durant la phase des tests d’intégration, l’application est chargée entièrement, dans un mode test. C’est l’équivalent du lancement de grails test run-app. Par conséquent nous disposons d’une base de données et de tous nos composants.

D’après Burt Beckwith, membre de la team Grails, il ne faut pas utiliser le framework de mock de Grails pour tester les classes de domaine. Sinon, tout ce qui est testé, c’est le framework de mock en lui-même et il ne supporte pas toutes les fonctionnalités de GORM (comme les closures withCriteria par exemple !). Pour les classes de domaine, il faut donc utiliser uniquement des tests d’intégration. L’exception à cette règle concerne les tests de méthode n’impliquant ni GORM, ni la base de données, comme les tests de validation de contraintes (regarder du côté de mockForConstraintsTests() pour ça).

Cette méthode est un peu radicale et suppose que, dès qu’on fait usage, à un quelconque endroit, de requêtes nommées ou de closures Criteria, on se retrouve obligé de ne coder que des tests d’intégration. Une alternative consiste à utiliser GMock pour combler les manques actuels de Grails.

Jeux de données

Lorsqu’on code des tests d’intégration il est important de connaitre le contenu de la base de données avant chaque test. Il est donc utile de pouvoir se baser sur des jeux de données pour initialiser la base. Parmi les nombreuses solutions qui s’offrent à nous, voici celles qui ont retenu mon attention :

• Utiliser la classe de configuration Bootstrap.groovy : Cela suppose de charger l’intégralité des données utiles pour tous les tests d’intégration, ce qui peut vite devenir encombrant. De plus le code nécessaire à instancier, lier et sauver toutes les instances utiles est assez verbeux.
• Le plugin DbUnit Operator : Permet d’injecter à la demande des jeux de données écrits en XML. Ce plugin est basé sur la librairie du même nom. C’est robuste et souple à la fois. L’inconvénient est que le modèle XML est centré sur le schéma de la base et va nécessiter une maintenance non négligeable.
• Le couple de plugin Fixtures/BuildTestData : Fixtures permet de créer des jeux de données et de les sauvegarder en base rapidement avec une syntaxe concise. C’est la solution qui m’a semblée la plus pratique. L’association avec le plugin BuildTestData autorise à raccourcir encore la définition d’entités. Les champs non remplis manuellement dans une fixture peuvent être remplis automatiquement par BuildTestData.

Après expérimentation, la dernière solution s’est révélée la plus simple et efficace. La documentation du plugin est un peu succincte et ne décrit pas de façon explicite tous les cas d’utilisation. En exclusivité, je vais prendre comme exemple un cas non documenté, sous vos yeux ébahis : l’utilisation conjointe des 2 plugins dans une fixture externe. Commençons par l’installation :

grails install-plugin fixtures
grails install-plugin build-test-data

L’installation du plugin Fixtures entraine l’apparition d’un répertoire fixtures/ à la racine du projet. Tous les fichiers de fixtures déposés dedans seront rendus accessible pour être chargé dans le code de nos tests. Il est possible de mettre directement les fixtures dans notre code (comme décrit dans la documentation) mais j’ai préféré l’option de chargement de fichiers externes pour éviter d’introduire du bruit dans le code. Voici une fixture appliquée à notre modèle :

fixtures/initialDev.groovy

import fr.xebia.nothunes.domain.*
import fr.xebia.nothunes.security.*
def member = User.findByUsername('user')
member.confirmPasswd = member.passwd
build {
  rtnp(Band) {
    name = 'RTNP'
    webSite = 'http://rtnp.org'
    owner = member
  }
  promotionCanape(Album) {
    name = "Promotion Canapé"
    band = rtnp
  }
  zombieNow(Track) {
    name = "Zombie Now"
    album = promotionCanape
  }
}

Décryptons ce fichier. Nous commençons par récupérer une instance de compte utilisateur en base, pour lui attribuer un Band. Cet utilisateur a été inséré dans la base via la classe de configuration Bootstrap, on peut donc compter dessus. La closures build sera interprétée par Fixtures pour créer les objets et les sauver en base. Fixture permet d’utiliser une closure build, qui s’appuie sur le plugin BuildTestsData, qui remplira automatiquement les champs non definis dans la fixture, de façon à ce que l’instance créée respecte ses contraintes d’intégrité.

Il est important de noter que les liens tissés entre les objets de la fixture sont écrits de façon directe. Par exemple la propriété band de notre instance promotionCanape est directement le nom de l’instance décrite juste au dessus. Pas besoin de sauvegarde intermédiaire, ce qui fait gagner pas mal de temps d’écriture.

Maintenant que nous disposons d’un petit jeu de données, pour le charger dans un test, il suffit de faire comme ceci :

package fr.xebia.nothunes.domain
import grails.test.*
import fr.xebia.nothunes.domain.*
import fr.xebia.nothunes.security.*
class TrackIntegTests extends GrailsUnitTestCase {
  // definition de l'attribut fixtureLoader pour injection automatique
  def fixtureLoader
  protected void setUp() {
    super.setUp()
  }
  protected void tearDown() {
    super.tearDown()
  }
  void testLoadFixture() {
    // chargement du fichier fixtures/initialDev.groovy
    def fixture = fixtureLoader.load('initialDev')
    def result = Track.listOrderByName()
    assertEquals 1, result.size()
    assertEquals 'Zombie Now', result[0].name
  }
  void testNotLoadedFixture() {
    def result = Track.listOrderByName()
    assertEquals 0, result.size()
  }
}

Comme on peut le voir, la durée de vie des données en base ne dépasse pas la méthode de test. Ce comportement est plutôt pratique pour éviter que nos tests d’intégration se polluent les uns les autres.

Test fonctionnels

Pour aller encore un peu plus loin dans les tests, il faut monter encore d’un cran et passer aux tests d’IHM. Une référence dans le monde du web en Java : Selenium. C’est le premier nom qui m’est venu et j’ai donc cherché un plugin Grails. Il existe bel et bien mais la documentation initiale m’a fait faire demi-tour. Les tests peuvent être rédigés en trois formats différents, je vous colle des exemple de chacun pour que vous puissiez juger :

• HTML :

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>test1</title>
</head>
<body>
<table cellpadding="1" cellspacing="1" border="1">
<thead>
<tr><td colspan="3">test1</td></tr>
</thead><tbody>
<tr><td>open</td><td>/selenium-test/</td><td></td></tr>
<tr><td>clickAndWait</td><td>link=BookController</td><td></td></tr>
<tr><td>clickAndWait</td><td>link=New Book</td><td></td></tr>
<tr><td>type</td><td>title</td><td>book1</td></tr>
<tr><td>clickAndWait</td> <td>//input[@value='Create']</td> <td></td></tr>
<tr><td>clickAndWait</td> <td>link=Book List</td> <td></td></tr>
<tr><td>verifyTextPresent</td> <td>book1</td> <td></td></tr>
</tbody></table>
</body>
</html>

• Pipe separated values :

open|/selenium-test
clickAndWait|link=BookController
clickAndWait|link=New Book
type|title|book2
clickAndWait|//input[@value='Create']
clickAndWait|link=Book List
verifyTextPresent|book2

• Groovy Server Pages :

<g:set var="bookTitle" value="book0d"/>
<sel:test name="MyTest">
<sel:row command="open" target="${request.contextPath}"/>
<sel:row line="clickAndWait|link=BookController"/>
<sel:row line="clickAndWait|link=New Book"/>
<sel:row command="type" target="title" value="${bookTitle}"/>
<sel:row line="clickAndWait|//input[@value='Create']"/>
<sel:row line="clickAndWait|link=Book List"/>
<sel:row line="verifyTextPresent|${bookTitle}"/>
</sel:test>

Si l’une de ces syntaxes vous emballe, faites en bon usage. Personnellement j’ai été refroidi par l’aspect très compact et plutôt dur à relire. J’ai donc continué mes investigations, et suis finalement tombé sur le plugin WebTest, basé sur la librairie de Canoo. Une librairie beaucoup plus orienté Groovy que ne l’est le plugin Selenium. De plus WebTest fourni également de jolis rapports HTML plein de couleurs attrayantes, faciles à interpréter. Voici un exemple de ce que peut donner le code d’un test simpliste avec cette librairie :

package nothunes
import nothunes.common.WebTestsNoThunes
class BandWebTests extends WebTestsNoThunes {
  def fixtureLoader
  void testLogin() {
    invoke(url:'login')
    verifyText(text:'Please Login..')
    def fixture = fixtureLoader.load('initialDev')
    invoke(url:'/navigation')
    verifyText(text:'RTNP')
  }
}

Les actions sont basiques, l’API est nativement en Groovy, et pour ceux qui ont déjà utilisé Selenium sur des projets Java, ce n’est vraiment pas dépaysant. La facilité de prise en main et les rapports parlants en font ma préférence pour l’automatisation de tests d’IHM web.

Analyse statique du code

Outre la pose d’un filet de sécurité autour des fonctionnalités de l’application, il est également intéressant d’affiner la qualité du code source produit. L’analyse statique de code est une méthode rodée chez les développeurs Java pour permettre de trouver des duplications de code, des bugs éventuels, évaluer la complexité, etc. Du coté du langage Groovy, l’outillage est un peu moins riche mais on trouve quand même quelques petites choses intéressantes.

CodeNarc

Tout d’abord : CodeNarc. Ce programme permet de valider du code Groovy en regard de règles de programmation établie. Un jeu de règle est proposé par défaut mais il est possible de définir ses propres règles. Un packaging sous forme de plugin Grails existe également, pour permettre une installation et une utilisation simplifiées :

grails install-plugin codenarc
grails codenarc

Cela va lancer l’analyse et générer un rapport détaillé de toutes les violations de règles, au format HTML :

Extrait de CodeNarcReport.html

La présentation est spartiate, mais ça tourne ! Le rapport commence par une vision macro avec la consolidation des erreurs par package, puis viens la liste détaillée de chacun des packages concernés, et enfin la description de chaque type de violation rencontré.
On peut également écrire soit même des règles de programmation à respecter. Il est donc aisé de se baser sur cet outil pour faire respecter les normes de votre choix. Pour ceux d’entre vous qui l’utilise déjà, sachez que la dernière version (la 0.11) est sortie le 13 novembre avec notamment 50 règles supplémentaires.

GMetrics

GMetrics, quant à lui, est centré sur le calcul et la présentation de métriques. Le projet assure le calcul :

• de complexité cyclomatique
• du nombre de lignes par méthode
• du nombre de lignes par classe

Selon le même principe que CodeNarc, l’installation de cette librairie se fait comme un plugin au projet : il se lance simplement et génère un rapport HTML :

grails install-plugin gmetrics
grails gmetrics

Extrait d’un rapport GMetrics

GMetrics est encore assez léger dans les métriques collectées, mais il offre une excellente base de développement pour collecter ses propres métriques. Si par hasard vous en écrivez pour un projet, n’hésitez pas à en faire profiter la communauté.

Conclusions

Il y aurait de quoi écrire un livre entier sur le seul sujet des tests dans le cadre de Grails. Comme d’habitude, les affinités entre le langage Groovy et le Java font que beaucoup d’outils Java sont déjà pluginizé ou ne coûterai pas cher à l’être. Longtemps cantonné aux scripting Java, le langage Groovy trouve ses lettre de noblesse avec Grails. Il est agréable de voir se développer pour le langage Groovy des outils de qualité qui apportent tant au langage Java. En quelques recherches, un projet peut se doter de tout ce qu’il faut pour développer des tests unitaires, d’intégration, fonctionnels mais aussi tests d’acceptance (avec Fitnesse ou EasyB), ou même des tests de vos fonctions Javascript avec JsUnit.

Dans le framework Grails, les tests sont disponibles pour tous les goûts, toutes les tailles. Le véritable défi consiste à séparer le bon grain de l’ivraie au milieu du foisonnement de plugins disponibles (sans compter qu’il est toujours possible d’intégrer soit même des librairies Java). J’espère vous avoir apporté, sinon La réponse, au moins l’éclairage de mon expérience personnelle sur le sujet. Maintenant il ne reste plus qu’à trouver votre propre style de tests Grails.

Ressources :

• Tests unitaires sur le site Grails
• Section Testing de la documentation officielle
• Mock Testing with Grails
• Testing your Grails application
• NoThunes sur GitHub

Nous essayerons dans cet article de montrer l’ergonomie d’Eclipse et l’utilisation du clavier pour rendre plus courte et plus agréable une session TDD. Nous présenterons quelques plugins Eclipse et aussi un outil souvent négligé que sont les templates de codes.

Un pattern sera introduit pour faciliter l’utilisation des objet métiers et POJO dans les tests.

Enfin, nous présenterons le concept important du Continuous Unit Testing appliqué à l’IDE et indiquerons et comparerons les plugins Eclipse pour le mettre en œuvre.

TDD et Eclipse

Raccourcis claviers utiles

La programmation sur ordinateur est née avant l’outil qu’est la souris pour PC. Tout développeur sait que privilégier le clavier à la souris aide à la concentration et apporte un gain de temps énorme.

Dans cet article, le but n’est pas d’avoir une liste exhaustive de raccourcis claviers utiles à la programmation mais plutôt de faire un résumé des raccourcis basiques en TDD. Ainsi, nous omettrons volontairement les raccourcis de refactoring qui pourront faire l’objet d’un autre article, le refactoring étant indissociable du TDD. Pour connaitre tous les raccourcis, voici un lien avec poster donnant une liste complète pour Eclipse. A placarder chez tous vos clients ou équipes de développement!

Raccourcis à connaitre lorsque l’on démarre TDD (ou la programmation…) avec Eclipse.

A noter que pour gérer les static imports trés courant en TDD, le menu Preferences/Java/Editor/Content Assist/Favorites permet de définir une liste de membres static. Le raccourci Content Assist vous suggérera ensuite cette liste même si l’import est manquant.

Key promoter

Une bonne méthode pour vous inciter à préférer le clavier à la souris est d’utiliser ce que l’on appelle les key promoter. Ce sont des plugins qui afficheront, au moyen d’une petite fenêtre, les raccourcis clavier à utiliser quand vous avez manqué à votre devoir de bon développeur! Voici les informations pour Eclipse et IntelliJ.

Un peu d’ergonomie

Eclipse vous offre une grande liberté quant à la disposition et organisation de vos vues (View) dans différentes perspective.

En TDD, la pensée et l’écriture du code font un va et vient entre la classe et sa classe de test correspondante. Cela peut paraitre un détail mais une façon de faciliter cela est de scinder votre vue éditeur java en deux comme le montre l’image suivante (cliquez pour agrandir).

Pour réaliser cela avec Eclipse, faites un click & drag sur un onglet dans votre éditeur et amener le vers le bas (tout en maintenant le button de souris) jusqu’à ce que la séparation de l’écran apparaisse.

Vous pouvez ainsi visualiser le code et les tests correspondants en même temps. Une façon de s’organiser et par exemple d’avoir vos tests dans l’éditeur du bas et vos classes dans l’éditeur du haut.

Eclipse Outline view

Une vue très utile à l’organisation et visualisation des tests est la Outline View. Elle permet de voir rapidement tous les noms des méthodes de test et agit ainsi comme documentation pour une classe. Mais surtout elle permet, en utilisant un drag & drop directement dans la vue, d’ordonner et de grouper logiquement les méthodes de test. Attention pour déplacer les méthodes de votre classe en utilisant la Outline View, le tri alphabétique doit être désactivé pour cette vue (petit bouton AZ dans le menu de la vue).

Ci-dessous un exemple de ré-organisation de méthodes

Templates de code Java

Les templates de code sont une description structurée de patterns de code qui sont récurrents au cours de votre programmation. Eclipse vient par défaut avec une série de templates courants très utiles (Preference > Java > Editor > Templates), mais vous donne surtout les moyens de créer les vôtres avec beaucoup de flexibilité grâce aux variables. Notez que les templates de code peuvent être importés et exportés au format xml très facilement avec Eclipse. Ainsi il est facile de les partager au sein d’un groupe de développement.

Lors de la création d’un template vous devrez choisir un nom et une description. Le nom de votre template se voudra être court et mémorable et peut contenir un chiffre pour faciliter le filtrage.

Par exemple pour générer une méthode de test avec JUnit 4, j’ai appelé mon template t4, et je donne une courte description qui m’aidera lorsque j’aurai de nombreux templates.

Pour ensuite utiliser le template, écrivez le nom du template et utilisez le raccourci du Content Assist (Ctrl + Space sur PC).

Voici quelques exemples de templates:

t4 – Generate Junit4 test method with Mockito imports

${staticImport:importStatic('org.junit.Assert.*')}${staticImport1:importStatic('org.mockito.Mockito.*')}${staticImport2:importStatic('org.mockito.MockitoAnnotations.Mock')}
@${:newType(org.junit.Test)}
public void should_${testname}() throws Exception {
	${cursor}
}

te – Generate Junit4 expected exception test method

${:import('org.junit.Test')}
@${testType:newType(org.junit.Test)}(expected=${expectionname}.class)
public void should_throw_${testname}_when() throws Exception {
	${cursor}
}

b4 – Generate Junit4 setUp method with Mockito imports

${before:import('org.junit.Before')}${initMocks:importStatic('org.mockito.MockitoAnnotations.*')}
@${:newType(org.junit.Before)}
public void initBeforeTest() throws Exception {
	initMocks(this);
	${cursor}
}

mk – Generate an instance field with the Mockito (@Mock ) annotation

${:import(org.mockito.Mock)}
@${mockType:newType(org.mockito.Mock)} private ${dependencyType} ${name};

Variables pour templates

La création de templates nécessite de savoir utiliser les variables de templates ce qui reste très simple. Il existe des variables génériques comme ${cursor} ou des variables définies par l’utilisateur qui peuvent donc être réutilisées dans le template. Ces dernières adoptent le format suivant:

• ${variableUtilisateur:operateurTemplate)}

Exemples:

• ${mockType:newType(org.mockito.Mock)}
• ${:newType(org.junit.Before)}

Le nom de la variableUtilisateur peut être laissé vide mais ce nom doit être unique pour chaque template (même vide) pour éviter les conflits.

Les templates trouvent leur sens lorsque la répétition est grande comme c’est le cas en TDD. Cependant, je pense qu’ils sont sous-estimés et encore trop peu utilisés. Faites place à votre imagination pour de nouvelles trouvailles et partagez-les au sein de votre équipe. La lassitude de coder et les tendinites devraient diminuer et la productivité augmentera.

Le plugin MoreUnit

Un plugin qui a commencé à réconcilier TDD et rendement est le plugin MoreUnit qui – après une période assez calme – est à nouveau en développement actif depuis l’été dernier. Une nouvelle version (2.2.0) sort d’ailleurs au moment où vous lisez ces lignes.

Voici les principales fonctionnalités de MoreUnit:

1. Il décore d’une icône verte discréte toutes vos classes testées. Un moyen rapide de voir ce qui ne l’est pas!
2. Lors du renommage ou du déplacement d’une classe, MoreUnit se chargera de renommer/déplacer la classe de test correspondante.
3. Un raccourci (Ctrl+J) vous permet de sauter de votre classe à sa (ses) classe(s) de test, un autre (Ctr+R) de lancer le(s) test(s) à partir de la classe principale.
4. Ces mêmes raccourcis vous proposent de créer la classe testée en fonction de la classe de test (et vice-versa) si elle n’existe pas, le tout en suivant vos préférences (voir point suivant).
5. Le comportement plugin est configurable de sorte que vous puissiez utiliser vos propres conventions (quelques exemples: préfixe « should » pour les méthodes de test, méthodes de test nommées selon les méthodes testées, pré-/suffixe « ITest » pour des tests plus orientés intégration, packages de test pré-/suffixés par « test. », tests placés dans un projet séparé, etc…).
6. Un dernier raccourci (Ctrl+U) vos permet de créer une méthode de test pour une méthode donnée, dans une classe de test existante et correspondant à la classe testée.
7. Enfin, MoreUnit supporte à la fois JUnit (3&4) et TestNG.

Cela fait maintenant plus de 2 ans que j’utilise moreUnit. Installez-le vous ne le regretterez pas.

Objet métiers et Builder Pattern

Une des tâches les plus ardues lorsque l’on pratique TDD consiste à générer les différentes instances des objets métiers qui seront utilisées pour les tests unitaires.

Imaginons que pour notre test unitaire nous ayons besoin d’une instance de la classe User comme suit

User user = new User();
user.setUsername("bob");
user.setSurname("Martin")
user.setEmail("bob@mail.com")
user.setPhone("+447735463526");

Le code ci-dessus est répétitif et n’aide pas à la lecture.

Une façon d’y remédier, en obtenant un code plus lisible et flexible, est d’utiliser le Builder Pattern. Nous obtenons ainsi des lignes de code simples comme celles-ci

User user = new UserBuilder().username("bob").surname("Martin").email("bob@mail.com")
                          .phone("+447735463526").toUser();

Si l’on veut juste un objet User vide ou l’un avec simplement un email, ce pattern le permet très simplement avec

User userWithEmail = new UserBuilder().email("bob@mail.com").toUser();
User simpleUser = new UserBuilder().toUser();

Voici ci-dessous la classe UserBuilder. Il est important de noter que le champ d’action de cette classe est réduit aux tests seulement et qu’elle n’apparaîtra jamais dans du code de production. Typiquement, en suivant les conventions Maven, cette classe résidera dans src/test/java.

public class UserBuilder {
	private String username;
	private String surname;
	private String email;
	private String phone;
	public UserBuilder username(String username){
		this.username = username;
		return this;
	}
	public UserBuilder surname(String surname){
		this.surname = surname;
		return this;
	}
	public UserBuilder email(String email){
		this.email = email;
		return this;
	}
	public UserBuilder phone(String phone){
		this.phone = phone;
		return this;
	}
	public User toUser(){
		User user = new User();
		user.setUsername(username);
		user.setSurname(surname);
		user.setEmail(email);
		user.setPhone(phone);
		return user;
	}
}

Il est parfois fastidieux de générer ce type de builder pour tous les objets métiers surtout s’ils sont imposants. Le plugin Eclipse suivant peut aider. Il génère un builder classique pour une classe donnée (la rendant par la même occasion immutable). Moyennant un peu de copier-coller en utilisant la classe produite par le plugin, on peut retrouver le builder présenté ci-dessus sans trop d’effort. Le site update de ce plugin Eclipse est ici.

Continuous unit testing avec Eclipse

Le test unitaire en continu est encore peu utilisé mais est un outil très puissant et indispensable pour le TDD. Il permet de se focaliser uniquement sur l’implémentation et la conception des tests, car votre IDE se chargera de faire tourner les tests unitaires et vous alertera lorsqu’un test est dans le rouge.

Le cycle classique de programmation en TDD est

1. Écriture du test
2. Lancer – par raccourci clavier – JUnit pour être dans le rouge
3. Écriture de l’implémentation
4. Lancer – par raccourci clavier – JUnit pour être dans le vert
5. Recommencer le cycle avec un autre test

Avec le test unitaire en continu, intégré dans votre IDE, votre cycle devient

1. Écriture du test
2. Écriture de l’implémentation
3. Recommencer le cycle avec un autre test

On en gagne du temps! Votre IDE (ou plutôt le plugin) se charge du reste… et c’est bien normal. Les développeurs sont là pour la conception après tout!

Les principaux plugins sont:

• JUnit Flux

Plugin gratuit et très simple d’utilisation. Il a cependant des problème de stabilité car la mise à jour et le rafraîchissement dans la JUnit View ne se font pas toujours correctement après un certain temps d’utilisation. Cela pose des problèmes car votre test est dans le vert alors qu’il devrait être dans le rouge! Cependant, c’est idéal pour commencer.

• JUnit Max

Développé par Kent Beck, il était tombé en désuétude mais a été remis sur le marché en Septembre 2010. Cependant, la licence reste chère à $100 par an! C’est peut être la raison pour laquelle je ne l’ai pas encore essayé. Je suis preneur de retour d’expérience sur ce plugin.

• Infinitest

Plugin stable au prix de $20. La notification de test en erreur se fait à l’aide de la Problem View (introduit par JUnit Max) ce qui veut dire que votre plugin ne tournera pas si vous avez une quelconque erreur de workspace. Un peu ennuyeux parfois. La configuration du plugin reste basique. Il n’y a en effet pas moyen de choisir sur quels projets dans votre workspace vous voulez appliquer le test continu. Ce qui veut dire qu’Infinitest, va faire tourner tous les tests de votre workspace. Le filtrage des classes de test par leur nom (pour éviter les tests d’intégration comme *.ITest) est un peu décevant puisque il faut ajouter un fichier de properties dans le projet au lieu d’utiliser un menu Eclipse dans les préférences.

Ayant commencé par utiliser JUnit Flux, j’utilise maintenant Infinitest et c’est celui que je recommanderais pour petit budget – vous pouvez l’essayer gratuitement pour 30 jours – en attendant sur le marché un plugin gratuit plus satisfaisant ou d’avoir le temps pour en développer un !

Conclusion

Aujourd’hui, le TDD est une arme que tout développeur Java (ou tout language qui s’y prête bien) doit avoir à son arsenal. Tout débat autour de cette méthodologie deviendrait inutile si tout le monde la maitrisait. En effet, chaque développeur, pourrait à son gré choisir de l’appliquer ou non en toute connaissance de cause.

Cependant, la maitrise du TDD demande du temps, de la méthode et surtout de la discipline.

Le but de cet article a été de promouvoir les pratiques indispensables. Elles permettent au développeur de se concentrer sur la partie fun du TDD en automatisant et en facilitant certaines tâches sans pour autant qu’il perde le contrôle.

Si la pratique du TDD n’est pas encore grandement répandue, j’espère que cet article aidera à faciliter son apprentissage.

Tour d’horizon

JTestR est un ensemble de librairies Ruby dédiées aux tests, alliées à JRuby pour permettre un démarrage rapide et sans douleur de l’écriture des tests. L’un des atouts principaux du scripting est la rapidité d’écriture, et Ruby est un langage de scripting devenu très populaire ces dernières années, notamment grâce à Ruby on Rails. Les tests unitaires et d’intégration font partie intégrante du monde Ruby et plusieurs outils ont vu le jour pour les faciliter. JTestR embarque les librairies de test Ruby suivantes :

• Test/Unit
• RSpec
• Expectations
• Dust
• Mocha

En tant qu’outil Java, il permet également des interactions avec les frameworks :

• JUnit
• TestNG

Dans sa dernière version, JTestR nécessite l’utilisation de Java 1.6.

Intégration

Livré sous la forme d’un jar avec une tâche Ant, il est facilement intégrable dans un projet existant. Une fois le jar disponible dans votre classpath, il suffit d’ajouter une balise taskdef à votre build.xml pour plus de confort et le tour est joué:

<target name="test" description="Runs all tests with default configuration of JTestR">
  <taskdef name="jtestr" classname="org.jtestr.ant.JtestRAntRunner" classpath="lib/jtestr.jar"/>
  <jtestr/>
</target>

Pour les projets Maven, une modification mineure du pom.xml fera l’affaire :

<!-- dans la section plugins -->
  <plugin>
    <groupId>org.jtestr</groupId>
    <artifactId>jtestr</artifactId>
    <version>0.4.0</version>
    <configuration>
      <tests>src/test/ruby</tests>
    </configuration>
    <executions>
      <execution>
        <goals>
          <goal>test</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

La directive de configuration tests permet de spécifier le répertoire dans lequel chercher les scripts de tests. Pour conserver l’esprit Maven, je vous conseille de créer un répertoire src/test/ruby et d’y placer tous les tests. La hiérarchie en sous répertoires pour représenter les packages des classes à tester ne pose pas de soucis.

Rédaction des tests

JTestR offre plusieurs possibilités pour la rédaction des tests. Tout d’abord, l’utilisation du framework de tests académiques de Ruby :Test::Unit. Cela n’apporte pas de grande nouveauté par rapport aux classiques tests JUnit. Le couteau suisse de méthode assert est disponible de la même façon.

Exemple de Test::Unit

class HashMapTests < Test::Unit::TestCase
  def setup
    @map = java.util.HashMap.new
  end
  def test_that_map_is_empty
    assert @map.isEmpty
  end
  def test_that_it_returns_a_keyset_that_returns_an_iterator_that_throws_exception
    assert_raises(java.util.NoSuchElementException) do
      @map.key_set.iterator.next
    end
  end
end

Mais il est également possible d’utiliser RSpec. Ce framework de tests est orienté « spécification » et propose une notation originale qui tend à rapprocher la rédaction des tests de la spécification du comportement attendu. La notation comparée :

# avec Test::Unit
assert_equals(result, 42)
# avec RSpec
result.should == 42

On se rapproche ainsi du langage naturel. En anglais dans le texte, certes, mais on se rapproche. La structure d’un fichier RSpec complet donne par exemple :

import java.util.HashMap
describe "An empty", HashMap do
  before :each do
    @hash_map = HashMap.new
  end
  it "should not be empty after an entry has been added to it" do
    @hash_map.put "foo", "bar"
    @hash_map.should_not be_empty
  end
  it "should be empty" do
    @hash_map.should be_empty
    @hash_map.size.should == 0
  end
  it "should return a keyset iterator that throws an exception on next" do
    proc do
      @hash_map.key_set.iterator.next
    end.should raise_error(java.util.NoSuchElementException)
  end
end

Il est possible de mixer dans le même projet des tests Test::Unit et des tests RSpec. Le respect d’une norme de nommage des fichiers suffit à JTestR pour déterminer le framework ciblé.

Une précision importante sur un point obscur dans la documentation : la commande import cherche dans les packages commençant par java, javax, org et com. Pour tous les autres il faut écrire :

import Java::fr.votre.package.VotreClasse

Limitations

Un problème qui peut être pointé du doigt est le temps de chargement de l’environnement JRuby. L’interpréteur prend en effet parfois plus de 10 secondes à se lancer. Pour pallier ce problème, JTestR possède un mode serveur qui permet de conserver en tâche de fond un serveur avec l’environnement JRuby en attente des tests à lancer. On supprime ainsi facilement le temps de chargement.

L’apprentissage des bases du langage Ruby peut également rebuter, mais c’est un obstacle faible dans la mesure où c’est un langage entièrement objet et où l’on manipule majoritairement les classes Java du projet à tester. Le pas est généralement franchi assez facilement.

Conclusions

L’offre de frameworks de tests est déjà conséquente dans le monde Java. JTestR n’est pas très répandu à l’heure actuelle. Malgré cela, l’utilisation de RSpec pour la rédaction des tests permet de rester proche d’une formulation verbale des comportements attendus. Dans une démarche TDD, cela peut être avantageux. On aura ainsi tendance à éviter de se perdre dans des formulations techniques dès les premières phases du projet.

De plus, je prendrai sérieusement en considération JTestR si j’avais des développeurs Ruby dans mon équipe. Le framework vous offre une chance de casser la frontière entre vos équipes Ruby et Java. L’aspect très concis des tests les rend lisibles autant par les développeurs Java que Ruby et renforce l’entraide entre équipes. Cela facilite la distribution des compétences et des connaissances entre développeurs, ce qui n’est jamais une mauvaise chose.

Ressources :

• Le site officiel JTestR
• La documentation
• RSpec
• Test::Unit