Les utilisateurs réguliers des applications Google s’en seront peut-être rendu compte, le géant de Mountain View a récemment mis en place un nouveau système de FeedBack consommateur pour bon nombre de ses outils. La plateforme sociale Google+ en a par exemple bénéficié directement à sa sortie et la dernière mouture de Blogger l’intègre également, suite au rachat de la société TalkBin en avril 2011, âgée alors d’à peine 5 mois.

L’objectif du système ?

Donner la possibilité à n’importe quel utilisateur d’envoyer un commentaire sur l’application qu’il est en train d’utiliser. Jusque-là rien de bien innovant, toutes les grandes applications disposent de ce genre d’outillage, généralement sous la forme d’un formulaire de contact.

Un peu plus intéressant, le commentaire peut être saisi par n’importe qui depuis n’importe quel écran de l’application, à travers un formulaire s’affichant en superposition à la demande. Là où le système devient génial, c’est que non seulement il donne la possibilité à l’utilisateur de mettre en surbrillance ou de masquer des zones de l’écran à l’aide de la souris (la capture du résultat final étant  expédiée aux équipes en charge de la maintenance de l’applicatif), mais en plus il intègre automatiquement un ensemble de paramètres techniques …

L’Elsass JUG s’est réuni le jeudi 19 Mai pour une soirée ‘Atelier Agile‘, avec Oana Juncu, scrum master et membre du board de l’Agile Tour. La soirée est à guichet fermé: le format ‘atelier’ ne permet d’accueillir que 35 personnes.

Agile c’est agile

Nous avons commencé par une présentation de quelques principes fondateurs de l’agilité, que je vous présente librement:

• le client c’est le client: l’objectif est de livrer un produit fonctionnel correspondant aux besoins. Ceci ne peut se faire que par une communication régulière avec le client du produit.
• le développeur développe: une communication régulière permet de maximiser le temps de développement efficace. De plus, seul le développeur sait quelle est la complexité des fonctionnalités à réaliser, il est donc associé pleinement à la planification du projet.
• l’heure c’est l’heure: chaque ’sprint’, c’est à dire chaque étape du projet telle que définies par Scrum, est définie par son ‘backlog‘, l’ensemble des fonctionnalités à implémenter, et par une date de livraison. Les fonctionnalités livrées peuvent être réduites, mais les délais sont toujours respectés.

• fini c’est fini: un produit livré ne doit plus être modifié. S’il est nécessaire de …

Un ch’ti Mockito ?

C’est avec grand plaisir que nous vous convions à la prochaine session du CH’TI JUG, qui se déroulera le mardi 20 avril prochain, à 18h30 à la Maison des Associations de Lille.

David Gageot, directeur technique d’Algodeal, nous présentera deux sujet lors de cette session : GIT et Mockito.

De nouveaux paradigmes de développement collaboratif émergent ces temps-ci et GIT constitue l’une des avancées techniques les plus remarquables dans ce domaine.

Mockito, quant à lui, parvient à s’imposer, dans un écosystème pourtant déjà richement fourni en frameworks de mocking, par la simplicité qu’il confère en matière de développement de tests unitaires.

Tous les détails concernant cette soirée sont sur chtijug.org.

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. Cela 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 …

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