Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Démontrer votre adhésion aux principes de Clean Code

Publié par David Beaumier le mardi 1 novembre 2011 à 22:18

Lors de la formation Clean Code certaines personnes m'ont demandées où elles pouvaient se procurer les articles qui démontrent l'adhésion aux principes promus par Bob Martin dans sa formation et son livre. Les articles (autocollant, bracelet, chandails, etc) sont en vente sur le site cleancoder.com. Fait intéressant, Bob n'exige pas de paiement pour l'article. Non, il demande plutôt qu'un don d'un montant proportionnel à la valeur de l'article soit remis à un organisme de charité de votre choix.

Je trouve que c'est une belle façon pour Bob de supporter la communauté des "développeurs propres" tout en aidant des organismes de bienfaisance. Lors du Agile Tour de Québec le comité organisateur a fait don des montants recueillis en vendant les articles offerts par Bob à la Fondation Gilles Kègle. Pourquoi ne pas poursuivre sur cette idée en appuyant l'infirmier de la rue tout en démontrant votre adhésion aux principes Clean Code? Allez-y, commandez votre article dès aujourd'hui et démontrez votre engagement à ne produire que du code de qualité!

Jusqu'à quel point dois-je tester mon code?

Publié par David Beaumier le vendredi 21 octobre 2011 à 15:49

Lorsque j'accompagne une équipe de développement, inévitablement on fini par me poser cette question (ou une variant de celle-ci): "est-ce qu'on doit vraiment avoir 100% de couverture dans nos essais unitaires?". C'est une question légitime et pertinente, mais c'est aussi une question qui sous entend que l'on n'a peut-être pas besoin de tester tout le code que l'on va écrire.

Pour répondre à la question, il faut revenir à la base et se demander pourquoi on fait des essais unitaires. Selon que les tests soient écrits avant (TDD) ou après le code d'implémentation on n'obtiend pas les mêmes bénéfices. Dans le présent cas, faisons abstraction des bénéfices offerts par le TDD et concentrons-nous sur l'essentiel: qu'est-ce que les essais unitaires sont censés prouver?

Selon Wikipedia, les essais unitaires doivent démontrer qu'une unité "fonctionne correctement en toutes circonstances". En se basant sur cette définition, comment peut-on garantir un fonctionnement conforme dans toutes les conditions si on n'a pas une couverture complète? Évidemment, on peut voir celà sous l'angle de la gestion des risques et il peut être acceptable de combler un manque de couverture unitaire par des essais intégrés plus complets. Toutefois, il s'agit d'une solution palliative qui ne fait que déplacer le mécanisme par lequel on garanti le bon fonctionnment de notre code. En plus, sachez qu'il est souvent plus simple de simuler toutes les conditions possibles au niveau unitaire que par des essais intégrés.

Évidemment, 100% de couverture ce n'est qu'une cible et rarement une équipe réussira à atteindre cette marque sur une base régulière. Ne soyez pas dogmatique et établissez plutôt une tendance de la couverture de code dans le temps et révisez-là fréquemment (à la revue de Sprint, par exemple). Si chaque fois qu'elle s'éloigne de cette cible l'équipe en profite pour se questionner sur les raisons qui font qu'elle n'a pas réussi à tester cette partie du code, il en résultera invariablement une amélioration des pratiques de conception et d'essais ce qui, en bout de piste, se traduira en un meilleur design de l'application.

En terminant, je vous invite à visionner cette vidéo qui présente le point de vue de Bob Martin au sujet de la couverture de code. Bon, j'avoue que Bob a vraiment un style bien à lui d'expliquer les chose, ce qui l'a ammené à apporter certaines clarifications dans ce second vidéo sur le sujet.

Études sur l’amélioration de la qualité par l’utilisation du TDD

Publié par David Beaumier le lundi 2 mars 2009 à 17:27

Un article publié dans le Empirical Software Engineering journal présente le résultats de quatre études qui comparent l'impact de l'utilisation de TDD sur la réduction des anomalies. L'article s'intitule Realizing quality improvement through test driven development: results and experiences of four industrial teams. Les auteurs proviennent de Microsoft, IBM et de l'Université de la Caroline du Nord.

Selon ses auteurs, l'article conclu que l'application du TDD permet une réduction variant de 40 à 90% par rapport à des projets similaires n'utilisant pas cette pratique de développement. Ils dénotent aussi une augmentation du temps de développement, mais comme je l'ai mentionné dans cet article précédent, il est fort probable qu'en comparaison les équipes témoin ne faisent pas (ou très peu) de tests unitaires. N'en demeure pas moins que l'augmentation de la qualité relevée est impressionnante.

InfoQ rapporte également une publication de Maria Siniaalto datant de 2006 dans laquelle l'auteur compare 13 expérimentations portant sur l'application de TDD dans divers contextes. Ses conclusions rejoignent celles de l'article du Empirical Software Engineering journal pour ce qui touche l'amélioration de la qualité. Fait intéressant, elle note qu'aucune étude à ce jour (2006) ne mesure l'impact de TDD sur la conception logicielle, alors qu'il s'agit pourtant d'un des première promesse de cette pratique. Tiens, un autre aspect de TDD sur lequel il me faudrait fouiller un peu plus et voir si des mesures ont été publiées au cours des trois dernières années.

Archive