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 …

De passage hier chez nos amis de Zenika, Cédric Vidal et moi-même avons eu le plaisir de faire la connaissance de Eric Evans, la référence mondiale du Domain Driven Design. A noter que Eric Evans fera une conférence sur ce sujet ce mercredi soir, 17 février, chez Zenika à Paris.

C’est surtout pour une rencontre tripartite ProxiAD / Zenika / Eclipse Foundation planifiée avec Ralph Mueller, Directeur Ecosystème pour l’Europe au sein de la Fondation Eclipse, que Cédric et moi avons fait le court trajet à pied de ProxiAD Ile de France à Zenika. Côté Zenika, Laurent Delvaux, cofondateur, Pierre Queinnec, cofondateur et directeur technique et Ophélie Rudent, responsable marketing, ont été nos hôtes pour cette réunion tout à fait passionnante, lors de laquelle nous avons notamment évoqué la stratégie de la Fondation Eclipse vis-à-vis du marché.

D’autres sujets brulants étaient à l’ordre du jour, mais il serait prématuré de les aborder aujourd’hui. Restez à l’écoute : nous devrions avoir d’ici quelques semaines de super nouvelles pour vous.

En attendant voici la traditionnelle photo souvenir avec …

Il y a de cela un peu plus d’un an, lorsque je cherchais un moyen de construire un plugin Eclipse avec Maven, je tombais presque par hasard sur une réponse laconique de Jason Van Zyl (le papa de maven): “Tycho”.
Mais, me diriez-vous : On ne pouvait pas contruire de plugin Eclipse avec Maven avant ???

Eh bien, en pratique, on pouvait parvenir à compiler des sources, à générer des fichiers manifest.mf voire à construire des “product” mais à quel prix ! A titre d’illustration, je vous invite à lire l’excellent article de Cyril Lakech et vous aurez une mince idée de la sueur et des larmes qu’il fallait accepter de verser pour mettre en place Maven sur des plugins avant d’apercevoir le graal.

Une autre alternative consistait à développer et maintenir ses propres “Mojo”; Grégory Levilain a ces dernières années ainsi développé et déployé sur de nombreux projets un ensemble de plugins Maven permettant d’adopter une optique “POM-FIRST”. Cette approche laisse à Maven le soin de gérer les versions des éléments du projet (plugins, fragments, features, update-sites, products), et de leurs dépendances. Ces travaux ont été initiés en 2006 lors de la mise en open-source du projet Wazaabi.

Mais alors …

Afin de résoudre une problématique complexe, il suffit presque toujours de la découper en autant de problèmes simples que nécessaire. Ce principe qui a fait ses preuves dans les sciences, qu’elles soient exactes ou non, prend tout son sens dans nos métiers.

Car, qu’on le veuille ou non, les attentes des utilisateurs sont là : les besoins en termes d’ergonomie, d’interopérabilité et d’évolutivité s’accroissent un peu plus chaque jour. Tout ceci contribue à rendre les systèmes d’information de plus en plus complexes. C’est aussi là que se trouve ce que j’aime faire : inventer des solutions simples et élégantes pour satisfaire des besoins toujours grandissant.

Développeur Java et architecte logiciel, mes thèmes de prédilection sont la modularité, l’évolutivité et l’extensibilité des Systèmes d’informations. Plus particulièrement, je m’intéresse aux cas d’utilisation de la norme OSGi et au développement de plugins Eclipse RCP.

La tête dans les étoiles, c’est préparer aujourd’hui les réponses aux problèmes de demain.

Voici comme promis hier un focus sur les thématiques que j’ai privilégiées lors de mon passage aux TechDays 2010.

En fait, je ne m’attarderai pas sur Office 2010. Ca fait maintenant 2 mois que j’utilise la version beta et cela marche plutôt bien. Sharepoint 2010 ammène également son lot de nouveautés avec en particulier un support avancé des ressources multimédia (videos notamment). Mais je m’écarte de mon sujet.

Il y a vraiment deux sujets que je veux mettre en valeur cette année.

Même pour un œil peu averti, il apparait évident que Microsoft continue son rapprochement vers les autres plateformes de développement. Ainsi n’ai je pas été le seul à relever hier les nombreuses références à PHP et à Java.

C’est d’abord avec le support souligné de PHP et Java sur Windows Azure dès la plénière du matin que le sujet est venu sur le tapis. Puis, dans l’après midi, une session, notamment, dédiée à l’industrialisation en environnements de développement hétérogènes a confirmé la tendance.

L’événement significatif en ce sens est le rachat par Microsoft fin 2009 de Teamprise de SourceGear. Teamprise est une suite d’outils qui permet à …

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 …

Voici une news qui a attiré mon attention : “MagicTest - an Automated Visual Approach for Testing“. Éliminer les assertions dans les tests unitaires est un concept séduisant. MagicTest réalise cela en instrumentant les classes de test et en se basant sur le résultat obtenu lors d’une exécution précédente du test, sous réserve que ce résultat ait été sauvegardé. Ainsi, pour consulter et sauvegarder les résultats, on dispose d’une console simplissime qui apporte une dimension visuelle plutôt agréable.

Console MagicTest

En supprimant les assertions, les tests sont plus rapidement codés et le traitement des exceptions, particulièrement, est habilement inhibé. Autre aspect attrayant expliqué dans cet article : un changement volontaire d’implémentation, ayant une répercussion sur le résultat des tests, n’implique pas nécessairement d’en modifier le code, comme cela aurait été le cas avec des assertions classiques. Ici, il suffit de valider/sauvegarder les nouveaux résultats obtenus après une simple consultation visuelle.

Sauvegarde de nouveaux résultats

Les tableaux produits par la console ne sont pas sans rappeler les “tables de décision” de Fitness, et bien que MagicTest n’a pas spécialement un caractère “collaboratif”, il pourrait bien constituer une alternative pour ceux qui n’apprécient pas …

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 …