Dans le développement des applications de gestion, de gros efforts sont axés sur la sécurité, la robustesse, et les performances. Hélas, un point essentiel est parfois délaissé : l’interface.

Au quotidien, j’interviens sur le développement des différents aspects d’application n-tiers (présentation, métier, accès aux données), au moyen des technologies Java usuelles. C’est cependant la couche présentation que je prends le plus de plaisir à développer, notamment l’interface à proprement parler.

Soigner l’interface, c’est offrir à l’utilisateur final la meilleure expérience possible, lui permettre de réaliser l’action qu’il souhaite rapidement et de manière quasi-instinctive. C’est aussi lui garantir qu’il pourra utiliser l’application quelque soit son navigateur, sa configuration, mais aussi sa condition physique. On parle alors d’ergonomie, de sémantique, de standards, de rétrocompatibilité, d’amélioration progressive, et d’accessibilité. Tout ceci constitue ou contribue à l’expérience utilisateur.

J’aborderai ce vaste thème lors de mes prochains articles sur ce blog, en partageant avec vous mon expérience et mon enthousiasme pour les interfaces utilisateur soignées.

L’Elsass JUG s’est retrouvé le 24 Février au CPPlex pour le premier JavaCamp organisé en Alsace. Vous connaissez le principe ?

Sur le modèle des BarCamps, les JavaCamps sont des ‘non-conférences’, dans lesquelles les speakers sont les participants. Les thèmes de la soirée ? Ceux qui motivent les présents: l’intégration continue, les serveurs Web avec JSF, l’agilité et la lazyness avec Google Guava.

La soirée JavaCamp commence par un tour de présentation: chacun est invité à se présenter en trois tags: agilité et web sont les mots clés qui reviennent.

Les Jugers sont ensuite invités à écrire sur des posts-it les thèmes qui leur tiennent à coeur. JSF et l’intégration continue sont les grands vainqueurs de ce premier sondage.

Préparation de la première session du JavaCamp

Session 1: Intégration continue, JSF

Je ne peux vous parler que de la session à laquelle j’ai participé: l’intégration continue consiste à construire régulièrement les builds des applications développées, pour s’assurer que la chaine de compilation, tests unitaires, tests d’intégration et packaging est stable. Une implémentation légère consiste en l’utilisation de Maven, qui …

Vendredi 19 novembre a eu lieu la 1ère soirée de l’Elsass JUG à l’EPITECH Strasbourg.

Près de 120 personnes de tous horizons (étudiants, enseignants, informaticiens et SSII) ont assisté à une soirée sous le signe du développement d’applications mobiles. Android était à l’honneur, comme il se doit au Java User Group, mais l’IPhone a été aussi dignement représenté.

Au programme :

• un retour d’expérience de mise à disposition d’une application sur la boutique Android Software, par Didier Girard ;
• des développements live d’applications Android ;
• puis une démonstration de l’étendue des possibilités d’Android face à IPhone, par le biais d’un jeu de rôles parfaitement exécuté par les membres de la jeune société Wakeapps.

Ce qu’on peut en retenir: une application qui vit est une application qui permet à sa communauté de s’épanouir - et qui permet aux développeurs de corriger les bugs avant que les forums publics type marketplace soit informés. Nous avons d’ailleurs eu une démonstration grandeur nature des effets de la communauté sur la qualité des applications: Didier a enfin pu emprunter le HTC Desire dont il avait besoin pour corriger un bug spécifique sur ce téléphone. A qui l’a-t-il emprunté ? A Wakeapps bien sûr …

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…