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 ?

…

Les tests unitaires classiques sont utilisés pour tester une partie du code d’une application, dans un environnement d’exécution bien maîtrisé. Même si les tests de ce genre sont nécessaires, et que leurs bénéfices ne sont plus à démontrer, il est également important de pouvoir réaliser de véritables tests fonctionnels d’une application web, en condition réelle, c’est à dire déployée sur un serveur d’application et en la testant depuis un navigateur. Selenium est un des outils les plus utilisés pour réaliser ce genre de tests. Après une présentation rapide de cet outil, cet article a pour but de vous exposer mon retour d’expérience sur son utilisation au quotidien.

Selenium est en fait un ensemble d’outils, dont les plus importants sont :

• Selenium IDE : plugin pour Firefox qui permet d’enregistrer et de rejouer des commandes utilisateur sur une application web - ouverture d’une URL, click sur un bouton, entrée d’une valeur dans un champ, etc. Ces commandes peuvent être exportées sous la forme de tests unitaires dans différents langages (HTML, Java, C#, etc.)
• Selenium Core : bibliothèque JavaScript, compatible avec un grand nombre de navigateurs, utilisée pour lancer les commandes utilisateur sur l’application web. Cette bibliothèque peut être utilisée directement pour lancer …

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…

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 …

J’évoquais dans mon post précédent l’utilité d’automatiser l’installation et la configuration des environnements de développement pour éviter que les outils visant au maintien de la qualité ne sombrent dans l’oubli à l’occasion d’une péripétie quelconque du projet, un renouvellement de l’équipe par exemple. Je prenais l’exemple de Checkstyle pour illustrer mon discours. Mais avec Checkstyle, une fois réglée la question de l’installation, on est vite confronté à un autre problème : son côté intrusif, à commencer par le grand nombre d’erreurs détectées d’emblée. “Ça va prendre du temps pour tout corriger.” “C’est quoi la complexité cyclomatique ?” “Il faut écrire la JavaDoc de toutes les méthodes ?” “Pas très pratique, lorsqu’on est en train de coder, de faire le tri entre les erreurs de style et les erreurs de compilation.” Autant de contraintes et de questions qui peuvent, petit à petit, décourager une équipe de développement. Il peut aussi arriver d’avoir à faire face à des remarques déroutantes du genre : “Pas grave, c’est juste un warning !”.

Pour éviter d’être pris au dépourvu, limiter les désagréments et faire en sorte …

Ça bouge en province. Après la première session du Ch’ti JUG le 13 mai dernier, le NormandyJUG, créé le 10 janvier 2009 suite au premier anniversaire du ParisJUG, propose sa première session le mardi 16 juin 2009 dans les locaux du Pôle Normand (à Mont Saint Aignan).

Les sujets choisis pour cette première rencontre sont :

• GWT vs Wicket : la bataille des frameworks Web présenté par Youen Chéné et Nicolas Giard. Youen Chéné est entrepreneur gérant la société Your Software 276, éditeur de Fermiers d’à coté, et également consultant en technologies (SOA, BPM, MDM, BAM, EAI). Nicolas Giard est ingénieur NTIC  et spécialiste Wicket.

• Tout sur l’Intégration Continue, Quoi, Pourquoi, Quand, Où, Comment et j’en passe, présenté Dimitri Baeli. Dimitri Baeli est usability manager chex eXo Platform. Il a, entre autres, en charge l’industrialisation de l’environnement de développement pour l’outil exo Plateform.

Pour assister à cette première session, vous pouvez (et devez) vous inscrire via le site jugevent.com.

L’essai brillamment marqué par l’équipe Ch’ti JUG lors de sa première session tenue il y a un mois est en passe de se transformer avec une seconde session le 15 juin qui s’annonce tout aussi passionnante.

Cette nouvelle session se focalise sur Maven 2 et les facteurs de réussite (et d’échecs) des projets qui en bénéficient. Pour en parler, c’est Arnaud Heritier qui se déplacera tout spécialement de la lointaine capitale jusqu’à Lille. Arnaud fait partie du comité de direction du projet Maven 2 chez Apache. Nous aurons donc, encore une fois grâce au Ch’ti JUG, l’information à sa source.

Les places disponibles pour l’événement restent limitées. Inscrivez vous donc très vite ici.

L’utilisation d’un outil d’analyse de code tel que Checkstyle, PMD ou FindBugs permet d’assurer un certain niveau de qualité sur un projet : l’outil garantit un code homogène et permet aux développeurs débutants d’acquérir progressivement une partie des bonnes pratiques de la programmation en Java. Mais le caractère optionnel d’un tel outil met en péril son adoption sur certains projets.

En effet, comme ce genre d’outils n’est nullement indispensable à la progression des développements, il est facile d’oublier de les installer. Du coup leur utilisation tient souvent de la bonne résolution de début de projet et finit par être délaissée au fur et à mesure que celui-ci prend de l’ampleur. Alors que les développements s’intensifient, de nouveaux développeurs arrivent, l’équipe se renouvelle, et Checkstyle n’est bientôt plus qu’un lointain souvenir. C’est en fait le lot de la plupart des outils liés à l’amélioration de la qualité et cela contribue à alourdir la dette technique des projets concernés (plus de détails sur la notion de dette technique ici).

C’est pourquoi, à mon sens, la mise en place de tout process qualité dépend en grande partie de la capacité …