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

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’ai eu l’occasion jeudi dernier d’assister à une présentation de l’outil de build Gradle par Hans Dockter, son fondateur. Cet événement était organisé par la société Zenika.

Dans son discours, Hans explique clairement avoir créé Gradle pour pallier au manque de flexibilité de Maven. Il souligne qu’avec Maven, on ne peut pas interagir avec les plugins, mais seulement les configurer de la façon spécifée. Ainsi, Gradle est un langage de build (et non un framework !) basé sur le principe qu’il est difficile de prévoir tous les scénarios auxquels nous pourrions être confrontés. Indéniablement, la présentation de Hans se déroule comme une partie de bras de fer avec Maven. Il anticipe immédiatement la question que tout le monde se pose : n’est-il pas risqué de s’affranchir des limites posées par Maven, sachant que c’est justement son caractère déclaratif et ses conventions qui en ont fait le succés, comparativement à ANT notamment ? A cette question Hans répond que nous sommes des informaticiens et que nous avons besoin d’outils pointus. “We need sharp tools”, dit-il.

Avec Gradle, les fichiers XML de ANT ou de Maven sont remplacés par …

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 …

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é …

Après 6 ans passés à évoluer dans le monde Java et Java EE, je suis depuis 3 ans responsable de l’industrialisation et des environnements de développement de ProxiAD Nord. Ce poste est né d’un besoin récurrent en SSII : assurer la maîtrise de ses développements, en termes de qualité et de productivité.

Vaste programme… et surtout un beau challenge parce qu’une application de qualité, c’est un peu comme une fricadelle : “tout le monde sait ce qu’y a d’dans, mais…”
Bref, le challenge est sur le long terme évidemment. Un process qualité peut facilement être perçu comme une contrainte si on tente de l’imposer de but en blanc. Et c’est généralement justifié car les actions visant à améliorer la qualité peuvent s’avérer pénibles et même paraître contre-productives.

Ma stratégie repose donc sur une approche plus globale dans laquelle le process qualité s’intègre à un ensemble d’outils et de services destinés d’une part à accroître effectivement la productivité sur le projet, d’autre part à fournir plus de confort aux membres de l’équipe. Dans ce contexte, les “actions qualité” retrouvent leur sens et leur plus-value. Cette méthode a l’énorme avantage de générer une demande plutôt qu’une contrainte.

Le thème de la qualité logicielle dans un …