Discuter:De l'importance des tests
Un article de Agile-Swiss.
Bonjour,
Cool l'article ! Si je peux encore ajouter mon grain de sel et ajouter des arguments à ta démonstration :
. Écrire un test va prendre du temps bien sûr ... De toutes façons, on va inévitablement vérifier que la fonction fait ce qu'elle est censée faire. Autant le vérifier de façon automatique plutôt que de vérifier ponctuellement.
Sur l'impossibilité d'écrire des tests, je trouve que se forcer à rendre son code testable améliore généralement le design.
Je me pose aussi 2-3 questions. Je ne comprends pas en quoi le client est un obstacle au TDD :
(S'il arrive très (trop) souvent que je doive renoncer au Test Driven Development, nombre de mes clients étant plus que frileux devant les méthodologies agiles et leurs pratiques,) Comment le client est il un obstacle à cette pratique ? Par une exigence de BDUF de sa part ?
Mets-tu en pratique DBC avec les assert Java ou utilises-tu un langage comme Eiffel ?
Merci,
s t
De toutes façons, on va inévitablement vérifier que la fonction fait ce qu'elle est censée faire. Autant le vérifier de façon automatique plutôt que de vérifier ponctuellement.
Oh que oui ! Mais curieusement, une proportion non négligeable des décideurs autant que des développeurs n'ayant pas pratiqué avec qui j'ai travaillé étaient d'emblée hostiles à ce qu'ils considèrent comme une surcharge inutile ou ennuyeuse de travail. Il me faut argumenter pour convaincre les décideurs et imposer ces pratiques aux développeurs pour qu'elles soient suivies, du moins lorsque ma position me le permet. J'ai moi-même eu à m'imposer d'écrire des tests, au début... seulement au début. :)
Comment le client est il un obstacle à cette pratique ? Par une exigence de BDUF de sa part ?
J'ai par exemple eu à intégrer des équipes existantes, et à me conformer aux pratiques établies. J'ai également essuyé un refus (une seule fois, mais quand-même) de toutes pratiques agiles d'un project manager intoxiqué Rational, hostile aux méthodologies agiles, sans compromis. Ou effectivement à des exigences de design au préalable, assorties de conventions de codage particulières n'intégrant pas de tests unitaires. "On ne maintiendra pas ces tests.". Bon. Je n'ai peut-être pas eu de chance...
Pour quelques projets, l'écriture de tests ne se justifiait pas. J'ai réalisé des portages de logiciels pour lesquels le travail d'écriture des tests excédait le bénéfice qu'on pouvait raisonnablement en retirer. J'ai aussi retravaillé des modules dont la durée de vie n'excédera guère quelques mois...
Mets-tu en pratique DBC avec les assert Java ou utilises-tu un langage comme Eiffel ?
Je n'ai malheureusement jamais eu l'occasion de travailler sur un projet avec Eiffel. Uniquement "à la maison". Mais j'ai développé des outils DbC pour C++, Java et Objective-C++. Pour Java, je n'utilise pas assert, mais mes propres routines et graphe d'exceptions. J'ai le projet de développer, lorsque l'occasion se présentera, un outil permettant d'écrire les contrats sous forme d'annotations... Ça pourrait se révéler intéressant.
Fabrice
Excelente idée la gestion des contrats via les annotations et merci Fabrice pour ce retour d'expérience sur les tests unitaires. Je témoigne également de la difficulté pour faire adopter les tests unitaires et principalement au niveau des développeurs. Ca demande clairement une remise en cause de son système de travail et dieu sait si nous les développeurs nous ne sommes pas toujours facile à bouger. Je suis également convaincu (pour le vivre actuellement) que le temps de développement d'une application est au final plus court avec les tests unitaires que sans. Quand les tests sont bien faits et systématiques on a nettement moins de bugs 'globaux' à corriger dans la douleur à posteriori.
Une note de plus à propos de la soi-disant perte de temps lorsque les développeurs écrivent des tests automatiques:
Lors d'un projet sur une grosse application WEB, la mise en évidence d'un bug requérait le démarrage du Serveur, celle d'un client, puis l'entrée de données assez techniques, généralement répartie sur plusieurs pages. J'ai personnellement mesuré le minimum temps que prenait un développeur en moyenne pour reproduire un problème: 18 minutes! Dans la pratique ce temps était plus long, car vu le nombre d'opérations requises pour parvenir à l'endroit désiré pour étudier le comportement erroné, une fois sur deux (au moins!) le développeur oubliait une chose et devait recommencer depuis le début. Le back-log des bugs en souffrances ne faisait que s'accroître.
Pour remédier à cet état de chose, j'ai mis en place une structure de test unitaires basée sur HttpUnit avec des primitives pour décrire les actions techniques (démarrages serveur + client) et métier, c'est-à-dire relative à l'application. Après quelque temps, les bugs prenaient moins de temps à être corrigés qu'ils étaient trouvé (les testeurs n'utilisant pas de tests automatisé!) et par conséquent le back-log des bugs a très vite disparu.
Dans d'autres projets, j'ai pu constaté que les développeurs passent plus de la moitié de leurs temps à reproduire les problèmes en faisant marcher l'application pas à pas. Même si le cycle de démarrage n'est pas aussi extrême que dans celui relaté ci-dessus, il reste que reproduire un problème manuellement reste un dépense de temps non négligeable.
La moralité de l'histoire est que l'existence de tests automatisés est un atout inestimable pour le développeur pour reproduire très rapidement toutes sortes de situations sur lesquelles il doit travailler pour tester son code. Loin d'être une perte de temps, les tests automatisés sont un gain de temps formidable pour tout développeur.
Didier Besset
