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 …

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

L’Agile Tour 2009 est passé par Lille et j’y ai croisé un intervenant que je connais bien, Grégory Ivanes. J’en ai profité pour le faire parler de l’événement. Ci dessous, presque en live

Arnaud Buisine : Bonjour Grégory. Peut-être deux mots sur toi avant de commencer ?

Grégory Ivanes : Bonjour. Ça va faire 8 ans que je suis chef de projets et en tout bientôt 10 ans que je travaille avec ProxiAD. J’interviens actuellement sur plusieurs projets en tant que Scrum Master. Ma certification date de début 2009.

Arnaud : Peux tu déjà me dire ce qu’est l’Agile Tour Lille 2009 ?

Grégory : L’Agile Tour est un évènement organisé localement dans 18 villes à travers le monde pendant tout le mois d’octobre 2009. Son objectif est de promouvoir et partager la vision de l’agilité ainsi que de fédérer et soutenir les initiatives locales des acteurs de l’agilité. Il s’est arrêté à Lille vendredi 30 octobre : http://www.agiletour.org/fr/at2009_lille.html

Arnaud : Où était ce ?

Grégory : Dans l’ancienne friche industrielle Le Blan-Lafont transformée par l’arrivée d’Euratechnologies (http://www.euratechnologies.com/).

Arnaud : En bref, de quoi avez vous parlé ? D’agilité je suppose ?

…

Dans la première partie de cet article, j’ai formulé des recommandations visant à éviter certains pièges lors du choix et de la configuration des règles Checkstyle. Cela notamment afin d’éviter de décourager les  développeurs avec des règles irréalistes ou hors contexte.

Reste à nous occuper des règles particulièrement pénibles à corriger, très laborieuses, telles que les espaces superflus, l’organisation des “imports” par ordre alphabétique, ou des variables selon leur visibilité.
Ce serait une perte de temps énorme que d’avoir à se soucier de tous ces problèmes syntaxiques. Heureusement la plupart des IDE actuels fournissent des outils qui, moyennant une configuration appropriée, peuvent réaliser automatiquement tous ces traitements. Je prendrai ici le cas d’Eclipse.

Bien configurer l’IDE pour éluder les contraintes de Checkstyle

Les “Save Actions” d’Eclipse permettent de systématiser le formatage du code ainsi que l’organisation des imports et des déclarations au moment de la sauvegarde des fichiers source. Cette option peut être utilisée de façon à résoudre toutes les règles de formatage de Checkstyle sans qu’aucune action spécifique ne soit nécessaire.

Cela nécessite de coordonner les règles Checkstyle avec les outils suivants :

• l’outil de formatage automatique du code (Window > Preferences …

Cette année, les Rencontres Mondiales du Logiciel Libre se tiendront du 7 au 11 juillet à Nantes. Elles affichent un programme très riche avec pas moins de 20 thématiques différentes réparties sur 5 jours.

Parmi ces thématiques un track MDSD, centré sur ATL, sera l’occasion pour la communauté d’animer le premier Eclipse Acceleo Day. Acceleo fait partie du projet Eclipse Model to Text (M2T). Les architectes ProxiAD seront présents lors de cet événement avec notamment une intervention le vendredi 10 en début d’après midi sur le Scaffolding MDD/MDSD.

L’accès à ces rencontres est gratuit. Pour vous enregistrer : RMLL 2009