En ce moment, je réalise des tests de montée en charge du serveur de reporting JasperServer. Je souhaite pouvoir corréler le niveau de stress (nombre de tirs simultanés) appliqué au SUT, le System Under Test, avec des métriques internes du serveur, à la fois système comme la charge CPU du process Java et la quantité de HEAP utilisée mais je souhaite aussi pouvoir mesurer des métriques propres à la librairie JasperReports comme le nombre de rapports en cours de calcul ou la vitesse de remplissage des rapports.

J’utilise JMeter pour effectuer les tirs. Cet outil permet de simuler plusieurs clients simultanés et de visualiser l’évolution des temps de réponse en fonction du temps et du nombre de clients qui tirent. C’est une vision boite noire, externe au SUT.

JMeter ne permet pas de visualiser des métriques propres au SUT comme la charge CPU, le nombre de transactions en cours, le nombre de requêtes SQL en cours ou dans le cas qui m’intéresse le nombre de rapports en cours de calcul.

Il existe plusieurs outils qui permettent de monitorer en temps différé ces informations comme par exemple HypericHQ ou l’une de ses nombreuses variantes, ils sont conçus pour du …

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Il va de soit que les tests représentent un gage de qualité pour un projet. Leur adoption dépend à mon avis de deux aspects :

• une bonne méthodologie ;
• une infrastructure adaptée.

Si les méthodes agiles et le TDD représentent un facteur de motivation, il serait dommage de ne pas les mettre en œuvre. Si ce n’est pas le cas, ou que le projet ne s’y prête pas, l’important à mon sens est de créer un besoin. L’un des aspects essentiels du développement assisté par les tests est de fournir un maximum de confort et de possibilités aux développeurs, afin de faire du test unitaire un outil de développement apprécié et indispensable.

Quelque soit la solution choisie, sa pérennité dépend fortement de la mise en place de l’infrastructure et de l’outillage nécessaires. L’intégration continue, notamment, est capitale.

Enfin, une solution de tests fonctionnels complètera efficacement l’une ou l’autre des méthodes citées.

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Gestion des données

Pour résumer, l’objectif est ici de placer la BDD dans un état prédéfini avant le test, de façon automatique, afin d’assurer sa reproductibilité. De plus, cette initialisation doit se faire :

• de façon suffisamment rapide pour que la durée d’exécution des tests ne devienne pas une contrainte ;
• de façon suffisamment souple pour injecter facilement toutes sortes de données. En outre, une méthode d’insertion dynamique permettra par exemple de créer des listes volumineuses pour tester un composant de pagination ou de tri.

Les tests contextuels nécessitent des jeux de données plus conséquents que les tests en isolation. Malgré tout, il est important que ceux-ci restent suffisamment légers pour conserver des performances acceptables.

Pour organiser ces jeux de données de façon optimale, nous distinguerons :

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

En pratique, que l’on choisisse le TDD ou une autre méthodologie, la complexité majeure de mise en œuvre réside dans la gestion des données de tests. La problématique consiste à placer la base de données dans un état prédéfini, avant l’exécution de chaque test, de façon automatique.

Par ailleurs, la politique de gestion des données est déterminante pour choisir les outils appropriés.

En TDD, les tests unitaires sont réalisés en pure isolation. C’est-à-dire que chaque fonction est testée en l’isolant de son contexte d’exécution afin d’éviter toute interférence externe qui risquerait de compromettre le résultat du test. C’est pour cela que les implémentations “mock” comme EasyMock ou Mockito (Mockito in six easy examples) sont très utilisées en TDD. L’isolation réduit aussi considérablement le volume de données de tests à gérer. Des outils comme DBUnit et SpringUnit, qui permettent de spécifier en XML les données attendues …

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Développement piloté par les tests

L’engouement pour les techniques “Agiles”, et plus particulièrement l’”Extreme Programming” a conduit de nombreux informaticiens à se demander si les méthodes TDD — “Test Driven Design” ou “Test Driven Development” — ne seraient pas la solution pour enfin promouvoir les tests dans leurs projets. En effet, en substituant l’approche traditionnelle “Coder-Tester-Déboguer” par l’approche “Tester-Développer-Remanier”, le TDD place les tests au cœur du processus de développement.

Mais ce qui rend délicat son adoption, c’est qu’il s’agit avant tout d’une méthode de conception “Agile”, à laquelle l’équipe projet doit être formée. Cette méthode a pour objectif premier de réduire les cycles de livraison. En codant le strict minimum requis entre chaque cycle, on évite les incompréhensions et l’on peut s’adapter aux changements.

Le cycle de développement préconisé est le suivant :

Aujourd’hui, le …

Comment promouvoir les tests dans le processus de développement d’une application de gestion Java EE ? Quels outils mettre en place ? Comment sensibiliser les développeurs ? Le développement piloté par les tests (TDD) est-il incontournable pour obtenir une solution pérenne ?

Le choix d’une solution de test est délicat. La multitude d’outils disponibles sur le marché est impressionnante. L’une des forces du TDD est qu’il repose sur une méthodologie clairement définie et des objectifs précis. Et c’est cette méthodologie qui détermine les outils nécessaires.

Dans certains cas, le TDD peut s’avérer inapproprié. L’essentiel pour obtenir une solution pérenne est alors de commencer par déterminer la méthodologie et les objectifs que l’on souhaite atteindre.

A travers cette série de billets, je vous présenterai ma vision des choses en comparant le concept de “développement assisté par les tests” à celui du “développement piloté par les tests”.

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Architecte et expert technique Java/JavaEE, je participe depuis plusieurs années à la mise en place et au développement de ces technologies sur un grand nombre de projets informatiques.

Confronté au quotidien à la réalisation d’applications, mon expérience du terrain m’a amené à mettre en place un certains nombre de pratiques ayant fait leurs preuves : tests unitaires, contrôle de la qualité, intégration continue, etc.

Mes thèmes de prédilection sont le monde de l’Open Source, la qualité logicielle, l’intégration continue et tout ce qui concerne l’automatisation des processus de développement, l’outillage du développeur, ainsi que les problématiques de conception et d’architecture des projets informatique. Ce blog est pour moi l’occasion de partager avec vous mon expérience et mon point de vue sur ces domaines.

En vous souhaitant bonne lecture…

J’ai un peu tardé à l’annoncer sur ce blog, mais nous avons enfin trouvé une grande salle pour recevoir la soirée Terracotta que le Ch’ti JUG, Terracotta  et ProxiAD vous proposent.

Cette soirée Terracotta dont je vous parlais déjà il y a quelques semaines et que nous avons été contraints de reporter est fixée au jeudi 15 octobre.

C’est grâce aux Formations en Informatique de l’Université Lille 1 que nous pouvons vous proposer une salle de 180 personnes.

Rendez vous vous est donc donné à 19 heures le 15 octobre, Amphithéâtre BACCHUS, bâtiment M5, Cité scientifique, Villeneuve d’Ascq (plan du campus ici).

Comme toujours, n’oubliez pas de vous inscrire ici.

Pour plus d”information rendez vous sur chtijug.org.

Le Ch’ti JUG et ProxiAD reçoivent Terracotta le jeudi 1er Octobre pour une conférence exceptionnelle. Celle-ci sera animée par un architecte Terracotta de passage en France. C’est à ne pas manquer : il fera tout spécialement le détour par Lille.

Terracotta est une solution open source de cache de données distribué (data grid) qui flirte avec les ténors du marché tels que Oracle Coherence et Gigaspaces.

Détails et inscriptions ici : http://chtijug.org/terracotta-proxiad/

Comme pour les sessions précédentes du Ch’ti JUG (JPA et Hibernate, Maven 2, J2EE 6), les places sont limitées et, en l’occurrence pour cet événement, déjà prises d’assaut. Dépêchez vous de vous inscrire !!

Mise à jour du 29/09 :
La soirée du 1er octobre est reportée à une date encore à fixer pour cause d’indisponibilité de dernière minute de l’intervenant.   Nous en profiterons pour vous proposer une salle plus grande et donc beaucoup plus de places.  La nouvelle date devrait se situer dans les 2 ou 3 semaines à venir. Donc restez à l’écoute !

…

Cet été, les vaillants organisateurs du Ch’ti JUG ne sont pas restés inactifs sur leur transat à se chauffer sous le soleil (très généreux cette année) de Lille.  Ils ont oeuvré pour maintenir le Ch’ti JUG sur la trajectoire du succès empruntée par les deux premières sessions sur J2EE 6 et Maven 2.

C’est donc en nous proposant de recevoir avec eux Emmanuel Bernard que le Ch’ti JUG à choisi de fêter la rentrée. Emmanuel est membre de l’équipe Hibernate, Core Developer chez Redhat/jBoss, développeur Hibernate Annotations et Hibernate EntityManager, membre des groupes d’experts EJB 3.0 et JSR-303. Autant dire qu’il aura des choses à nous dire sur JPA2, Bean Validation et Hibernate Search, les sujets retenus pour cette nouvelles soirée lilloise.

La date ? Le lundi 21 septembre.

Pour plus d’information, restez à l’écoute de chtijug.org et de ce blog, bien entendu.

Mise à jour : L’annonce définitive (avec l’adresse notamment) et le lien pour l’inscription sont ici.