jeudi 22 décembre 2011

TDD : "Les Tests en Trois Temps"

Parmi les pratiques agiles les plus connues et/ou les plus appréciées, on retrouve les Développements Dirigés par les Tests (Test Driven Development en anglais ou TDD). Les TDD font grand bruit depuis quelques années déjà. Conduire un projet en utilisant les TDD est gage de réussite, de bonheur et de longue vie. Toutefois, tout n’est pas si rose dans le petit monde du logiciel.

Le premier principe des TDD est d’écrire des tests avant de coder l'application. Les développeurs peuvent ainsi s’appuyer sur lesdits tests pour valider que les fonctionnalités correspondent bien aux attentes du client. Plus précisément, la méthode conseille de faire initialement échouer les tests puis, progressivement, de coder l’application pour que tous les tests passent.

Le site developpez.com propose une présentation (en français) des TDD.

Dans la réalité, peu d’équipes jouent le jeu bien longtemps. Un des plus gros défauts de la méthode est aussi une de ses qualités. En effet, hormis le principe de base décrit plus haut, les TDD laissent beaucoup de libertés aux développeurs. Très vite, on se rend compte que "trop de libertés tue la liberté". La plupart des développeurs ont besoin d’un cadre de travail clair, faute de quoi on ne sait rapidement plus par quel bout prendre l’affaire.

Plus concrètement, la méthode ne précise pas qui spécifie les tests, qui les écrit, selon quelles normes, qui les vérifient, dans quel ordre ils doivent être créés et/ou exécutés, comment on se sert de ces tests pour coder les fonctionnalités, etc... Chaque membre de l’équipe est laissé seul devant ces questions, qui finissent par le dépasser. Au mieux chacun travaille en fonction de ses propres interprétations. Il en résulte d’abord des séries de confusions, des pertes de temps plus ou moins importantes, des divergences critiques, pour finir après quelques temps sur l’abandon pur et simple de la méthode.

Le pire des cas est lorsque tout ce "non cadrage" n’est pas détecté. Les conséquences peuvent alors prendre des proportions démesurées et faire échouer le projet entier. On a ainsi vu des équipes envoyer en production leurs projets, pensant en tout bonne foi que 100% des besoins étaient couverts, et se rendre compte le jour J que rien ne va. Ici on ne parle même pas de la dégradation progressive de l’ambiance et des conditions de travail.

Partant de ces constats, Thierry s’est imposé des règles simples à suivre dans le cadre des Développement Dirigés par les Tests. Pour cela il s’est attelé à se mettre dans la peau de chaque acteur d’un projet classique (chef de projet, développeur, testeur, client, etc.) et identifier les attentes et besoins de chacun. Il a pris en compte des considérations sur les coûts, les délais, les responsabilités, la simplicité, le respect des normes et de la qualité, la communication, sans oublier l’ambiance générale et le travail en équipe.

Après quelques tentatives et ajustements, Thierry a proposé une simplification cadrée des TDD qui se décompose en trois phases successives qu’il a naturellement nommé "3T". Les "Tests en Trois Temps" (3T) ont été présentés sur le site developpez.com ici.

La proposition 3T se décompose comme suit :
1) Le développeur A écrit une Interface décrivant le service à programmer. Les fonctionnalités correspondent exactement à ce qui est indiqué dans le cahier des charges. Chacune des règles mentionnées est recopiée, numérotée, référencée. Si besoin, on fait un aller-retour avec la MOA pour mettre à jour les spécifications. Le développeur A ne fait que recopier ce qui est écrit. Sa seule valeur est de transformer des mots en français vers du code source de qualité. A ce stade, il ne programme pas la fonctionnalité ; il ne fait que la décrire.
2) Le développeur B part du travail réalisé par A. Il écrit des tests complets en s’appuyant sur les interfaces écrites durant la première phase. Chaque règle mentionnée doit être reprise et testée séparément. Chaque exemple fournit fait l’objet d’un test spécifique. Le développeur B rédige ses tests selon une norme précise, s’inspirant de AAA (Arrange, Act, Assert), et commune à l’équipe. A la fin, tous les tests doivent échouer car la fonctionnalité n’a pas encore été développée.
3) Enfin, le développeur C programme la fonctionnalité demandée. Pour cela il s’aide des tests qu’il doit faire réussir progressivement. Chaque étape de ce processus est prise en charge par un développeur différent. Cela évite les tests de complaisance. Cela permet également de bien séparer les responsabilités et d’éviter de se mélanger les pinceaux. En outre, chaque développeur peut s’appuyer sur des bases très solides, rendant les temps successifs relativement simples ; il suffit souvent de recopier. Bien entendu, le travail réalisé à chaque étape peut faire l’objet d’une livraison, garantissant encore plus la qualité globale.

Pour aller plus loin, Thierry s’est demandé comment coupler 3T aux autres pratiques Agiles comme Scrum ou Kanban. Il a présenté un article humoristique sur le site de developpez.com, mettant en œuvre (et en pratique) quelques pistes, et disponible ici. Dans cet article, il met notamment en scène différents acteurs (cdp, développeur, architecte, client, etc.) du projet, ainsi que leurs attentes respectives, à travers plusieurs versions du produit.

1 commentaire:

  1. Très bon article. Vraiment intéressant, comme le reste du blog d'ailleurs.

    RépondreSupprimer