Agilité 2: Test Driven Development

September 29th, 2004 par Freddy Mallet

Le TDD est une des pratiques d’XP. Cet article sur TDD de Scott W. Ambler n’est pas très récent mais par contre je suis tombé dessus récemment et je le trouve relativement limpide.

Il insiste notamment sur le fait que le TDD permet bien sûr d’assurer la non-regression du code et de refactorer en aillant ces arrières assurés mais également, et c’est à mon sens tout aussi important, d’assurer une ‘qualité’ de conception objet. En effet si vous appliquez correctement le TDD, vous commencez par coder le test puis la fonctionnalité souhaitée. Conclusion, le fait de coder le test vous contraint à penser en terme d’interface et d’avoir les idées très claires sur ce que l’objet que vous allez coder doit offrir. Impossible par conséquent de partir la tête dans la guidon en criant ‘Inchallah’.

Contrairement à RUP qui conseil fortement de tout modéliser avant de débuter le développement (because vente des licences des produits rationnal), XP répond sur le principe que c’est beaucoup d’énergie perdue en conceptualisation et qu’il n’est jamais trop tôt pour commencer à coder. Le TDD permet justement à mon sens de canaliser en permanence cette phase de codage en XP pour assurer une bonne conceptualisation même si cette dernière n’a jamais été formalisée.

Pour ce qui est de l’intérêt que représente ces tests en terme de documentation je suis un poil plus mitigé. En effet, je veux bien croire qu’un jeu de tests unitaires sur une classe permet de comprendre les services offerts par cette classe mais je doute que cela puisse apporter aisément une compréhension de la logique plus globale. Cela me semble donc plus un type de documentation important mais pas suffisant.

3 Responses to “Agilité 2: Test Driven Development”

  1. Jerome Says:

    Amusante coïncidence, j’étais justement tombé dessus lundi via la page de ressources du projet DBUnit (www.dbunit.org), projet dont je voulais parler, ce dernier permettant de faciliter les tests unitaires en initialisant l’état des Bases de Données entre ceux-ci. Technique plutôt utile au sein de projets de type Database-Driven Development (c’est une vision comme une autre). D’autres trouveront certaines similitudes avec les premières versions d’un feu “ftest”;). Le problème c’est que je n’arrive toujours pas à me loguer sur Wordpress :( Bref, je vous invite à aller visiter le site du projet si jamais (je ne vais pas détailler dans mon commentaire, ce serait mal vu :p )

  2. Freddy Mallet Says:

    Le sujet est d’actualité sur TSS (The Server Side) avec cet article de Dave Astels qui pousse a avoir un regard critique sur son propre code. Il est vrai que l’informaticien (et j’en suis) a toujours tendance à tomber dans l’exès de jugement négatif sur le code d’autrui en oubliant l’importance de l’auto-critique.

    Dave Astels dirige une SSII qui cherche à promouvoir les méthodologies agiles Adaption.

  3. Eric Vautier Says:

    Articles et ressources sur TDD, les tests d’acceptance et l’intégration continue sur le site testdriven.com.

Leave a Reply

You must be logged in to post a comment.