10 questions et réponses de newbie* à  propos du TDD

La mer

* En fait la newbie c’est aussi moi. Il s’agit des questions que je me suis moi-même posé plus ou moins récemment et des réponses que j’ai trouvé.

Je ne sais qu’une seule chose, c’est que je ne sais rien (Socrate)

1) D’où ça vient le TDD ?

Le TDD (Test Driven Development) est une méthode employée dans la méthodologie Extreme Programming.

C’est quoi l’Extreme ProgrammingSmiley souriant

C’est une méthodologie agile qui se concentre sur la réalisation et la production ainsi que sur la partie gestion de projets.

En cela, elle diffère des méthodologies dont on entend peut-être plus souvent parler comme le Scrum ou le Kanban.

Les joies les plus pures sont les plus extrêmes (Bjork)

Cette méthodologie a été mise en place par Kent Beck, Ward Cunningham et Ron Jeffries.
Elle voit officiellement le jour en 1999 avec le livre Extreme Programming Explained de Kent Beck.

Par la suite, Kent Beck a fait un focus sur le TDD avec son livre Test Driven Development: By Example paru en 2003.

2) Comment définit-on le TDD ?

Pour cette partie-là, je vous propose de reprendre les points qu’expose David Astels dans son livre Test-Driven Development: A Practical Guide :

  • Aucun code ne part en production sans avoir été testé
  • Les tests sont exhaustifs
  • On écrit ses tests avant le code

3) En quoi ça va rendre mon code agile ?

Alors oui, si le TDD est une méthode de développement issue d’une méthodologie agile, en quoi est-ce que ça va rendre mon code agile ?

En pratiquant le TDD, on obtient un code plus testable, donc découpé en fonctions qui présentent des unités fonctionnelles.
De plus, le code est plus facilement mockable et bouchonnable puisqu’on a pensé à ces choses dès le début. Donc, les rôles de chaque entité sont séparés.

Le code est censé être plus robuste et alors plus facilement étendable et modifiable Smiley souriant.

4) Comment ça marche en fait ? Il faut que j’écrive tous mes tests puis que je rédige tout le code correspondant ?

Non, il s’agit d’écrire le minimum pour que le test plante et d’y répondre avec le minimum de code pour que le test passe.

5) A quel point ne dois-je écrire que le strict minimum pour que mon code passe ?

Ben oui, on dit toujours ça qu’il faut rédiger le minimum de code pour faire passer un test.
Donc si le test attend 2 d’une addition, je peux renvoyer « return 2 » ?
Eh bien oui Smiley diable
Mais nous n’en restons pas là .

David Astels explique justement qu’il y a 2 écoles après avoir posé ça :

  • Soit on ajoute un deuxième test et on se rend compte que la façon dont notre fonction est faite n’est pas viable
  • Soit on considère ce « 2 » comme une constante non voulue qu’on transforme par du code (phase de refactoring).

6) Quand est-ce que je réactore ?

L’idée normalement, c’est d’écrire un test, de rédiger le code qui y répond et de refactorer.

Cependant, j’aime bien l’idée de voir le TDD comme un jeu de ping pong où ping on écrit un test, pong on rédige le code, ping on écrit un autre test, pong on rédige le code, jusqu’à juger nécessaire la refactorisation.

7) Je dois vraiment être à 100% de code coverage ?


Eh bien normalement oui puisque l’un des points de la définition (en tout cas celle que donne David Astels, mais aussi d’autres adeptes du TDD) est d’être exhaustif Clin d'oeil.

Aucun code n’est censé partir en production sans avoir été testé et tout code doit répondre à un cas de test.
Finalement, tout ce qu’on code est censé répondre à un cas fonctionnel.

Donc naturellement, on devrait arriver à  un code coverage de 100%.
Pourtant, dans les faits, les projets qui pratiquent le TDD, même s’ils s’en approchent, ne sont pas à 100%.

Enfin, pas à  ma connaissance Smiley souriant.

8) Le TDD, c’est facile ?

Non ou plutôt ça s’apprend. Ce n’est pas inné. C’est un peu surprenant comme manière de faire.

Commencer par écrire les tests d’un code qui n’existe pas peut sembler être un contresens et ce n’est pas évident.

9) Et comment ça s’apprend ?

Coding dojo, expériences personnelles et collectives sur toute sorte de projets, …

Une méthode que j’aimerais bien tester est de se mettre en pair. L’un écrit le test et l’autre l’implémentation.

Elephpants en pair programming

10) Le TDD, est-ce vraiment la solution qu’il me faut ?

La mer

Eh bien, le TDD ça apporte tout un tas de bénéfices, mais si vous avez une solution qui les apporte aussi, alors c’est aussi intéressant.

Il m’apparaît que l’idée est de trouver sa voie dans le TDD pour tirer pleinement profit des avantages de cette méthode sans dogmatisme Clin d'oeil.

 

Bibliographie qui m’a aidé à rédiger cet article :

Livres

  • Clean Coder, Robert C Martin
  • Clean Code, Robert C Martin
  • Test-Driven Development: A Practical Guide, David Astels

Liens internet