L’impact du TDD sur la productivité

Publié par David Beaumier le lundi 2 mars 2009 à 15:53

Parmi les études sur l'utilisation du TDD recensées sur Internet, on retrouve un cas qui implique deux équipes de produits chez Microsoft (dans les divisions Windows et MSN). Dans les deux cas étudiée chez le géant de Redmond, l'impact de la pratique de TDD sur le temps de développement et sur le nombre d'anomalies ont été mesurés. En se basant sur les données recueillies, l 'étude démontre que la qualité du code livré est de beaucoup supérieure lorsque l'équipe applique TDD. Les mesures ont permis d'identifier une augmentation de 4.2 fois dans la qualité du code développé en utilisant TDD lorsque comparé à une projet réalisé dans un contexte organisationnel similaire mais n'utilisant pas cette pratique.

Toutefois, l'étude fait ressortir le fait que les programmeurs utilisant une approche TDD sont moins rapide. L'écart rapporté est de 16%. En se questionnant sur cet écart je crois nécessaire d'apporter un bémol par rapport au chiffre avancé. En effet il est beaucoup plus facile de calculer le temps total engagé pour développer une fonctionnalité lorsqu'on utilise TDD que lorsqu'on utilise une approche traditionnelle. La notion "d'avoir terminé" une fonctionnalité donnée est beaucoup plus claire avec TDD. En mode traditionnel, avoir terminé est plus une question de confiance par rapport à ce qu'on a réalisé; confiance qu'on a produit du code assez robuste et couvrant l'ensemble des attentes. Avec TDD, avoir termin. une fonctionnalité se produit lorsque l'ensemble des tests unitaires s'exécutent avec succès. Je crois qu'une grande partie de la réduction des anomalies notée dans l'étude de Microsoft est dû à cette formalisation de la notion  "d'avoir terminé".

Les auteurs ont d'ailleurs eux aussi apportés une nuance face à cet écart en indiquant que "les programmeurs du groupe de contrôle omettaient fréquemment de réaliser les cas d'essais automatisés après avoir complété leur code". Cela n'est pas surprenant en soi et c'est un phénomène fréquent dans les équipes n'utilisant pas TDD. Dans ce contexte, les tests sont réalisés après le code et deux raisons sont fréquemment cités pour justifier le fait d'escamoter les essais unitaires.

  • Contrainte dans le temps
  • Conception limitant la capacité de tester unitairement le code

Même en prenant pour acquis que la réduction de productivité est bien de l'ordre de 16%, cela demeure tout de même un bien faible coût à payer en regard des bénéfices de qualité généré. Sachant que plus une anomalie est découverte tardivement dans le cycle de développement plus elle est coûteuse à régler, une réduction de plus de 4x du nombre d'anomalie apporte une économie de beaucoup supérieure à l'augmentation possible du temps initial de développement.  Dans cette optique cet écart, s'il est bie réel, devrait plutôt être considéré comme un investissement.

Une présentation de Philip Ritzkopf fait une synthèse intéressante de quelques expériences et études portant sur la pratique du TDD. Dans sa conclusion (à la page 40), on peut voir que, dans l'ensemble, l'utilisation de TDD ne réduit pas la productivité des développeurs. L'application de TDD n'engendrerait donc pas l'instauration d'une "taxe" au développement comme plusieurs pourraient le croire.

L'article publié en 2005 par Erdogmus, Morisio et Torchiano dans IEEE Transactions on Software Engineering présente les conclusions d'une expérience comparant le travail de deux groupes d'étudiants, où l'un appliquait une approche TDD alors que l'autre rédigeait les tests après avoir avoir terminé le code. Dans les deux cas les participants devaient appliquer une approche incrémentale en ajoutant les fonctionnalités une par une et en s'assurant de ne pas avoir introduit de la régression entre chaque cas.

Les auteurs arrivent à la conclusion que les participants ayant appliqué TDD on généralement écrit plus de tests que ceux ayant écrit les tests après.  Aussi, ils ont remarqué que la courbe de productivité a tendance à augmenter en fonction du nombre de tests. Les auteurs de l'étude suggèrent que ces gains en productivité découlent des éléments suivants:

  • Meilleure compréhension de la tâche à réaliser
  • Focus sur la tâche à accomplir
  • Apprentissage plus rapide
  • Réduction de l'effort de réécriture du code

Dans un premier temps, on voit que le fait de travailler par petites étapes et d'avoir toujours comme objectif à court terme de faire passer un test permet au développeur de focuser son attention sur une activité bien précise tout en ayant une meilleur compréhension de celle-ci. On réduit ainsi les chances d'être distrait pas une préoccupation provenant d'un autre aspect du système que celui sur lequel on travaille. Les trois auteurs notent que l'application du TDD par les participants "encourage une meilleure décomposition, augmente la compréhension des exigences et réduit la portée de la tâche à réaliser".

La plupart des études citées cherchent à mesurer l'impact à court terme de l'application du TDD. Il s'en dégage clairement une tendance où l'on constate que l'impact sur la productivité de l'équipe est négligeable, voir même nul. Dès que l'on introduit l'élément qualité dans l'équation, l'amélioration générale constatée dans les études rend non-significatif tout impact sur la productivité.

Par contre qu'en est-il des impacts sur la productivité à long terme? Est-ce que l'important patrimoine de tests qu'engendre la pratique du TDD affecte la capacité de l'équipe à avancer au même rythme au fil du temps? Je reviendrai sur ce sujet en espérant apporter des réponses à ces interrogations dans un prochain article.

blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.