Test Driven Development By Example

Test Driven Development By Example

Livre Test Driven Development By Example

Comprendre la pratique TDD

En choisissant de lire Test Driven Development By Example, j’ai voulu comprendre concrètement ce qu’était TDD. Comprendre comment cette technique se pratique, quels sont ses bénéfices mais également ses limites. C’était important pour moi de bien comprendre et de pratiquer TDD avant d’essayer de motiver mon équipe ou futures équipes à utiliser une telle technique. L’ensemble des mes attentes ont été comblées.

TDD est bien plus q’une technique de test

Beaucoup de choses. Ce livre est un livre comme je les aime : très riche tout en restant synthétique. J’en suis arrivé à la conclusion que TDD n’est pas une technique de test mais une technique d’analyse, de conception et plus encore. Une technique qui structure l’ensemble des activités de développement.

Le fait de commencer par rédiger le test avant le code à tester permet de perdre moins de temps à rédiger ces tests (en économisant par exemple le temps nécessaire à répondre à la question « comment vais je tester le code que je viens de développer » voir le temps nécessaire à rendre le code accessible par les tests, ouvert). Cette approche permet également de s’assurer que son test fonctionne au sens où il alerte bien en cas de régression (cf. rouge/vert/refactoring). Les tests ainsi efficaces, permettent de réduire le stress du développeur et d’éviter de tomber dans la spirale infernale : « plus le développeur est stressé > moins il teste > plus il y a de bugs > plus le développeur est stressé ». Ces tests efficaces donnent la confiance nécessaire à l’intrépidité du développeur. Nécessaire elle même au travail de refactoring. Enfin TDD permet d’aboutir à un code simple, sans duplication, peu coûteux à maintenir : « code pour demain, conçois pour aujourd’hui » plutôt que « code pour aujourd’hui, conçois pour demain ». TDD permet également au développeur de canaliser ses efforts en évitant de penser à 50 choses en même temps. Sa feuille de route est sa liste de tests à écrire. TDD apporte également un côté fun dans sa pratique au sens où on manie l’art du copier-coller et de la triche en règle avec l’usage du fake (bien entendu tout cela au service de la qualité et de sa sérénité).

Ma compréhension de l’anglais sur cet ouvrage n’a pas été facile. Kent Beck utilise parfois un vocabulaire plus élaboré que d’autres. J’ai par exemple lu bien plus facilement Agile Project Management With Scrum de Ken Schwaber.

En gros le bouquin est organisé en différentes parties, les 2 premières sont des exercices de pratique de TDD. Un premier assez simple et un second plutôt ambitieux : coder un framework xUnit en langage Python en approche TDD (donc sans framework xUnit au début). On pourrait penser que l’auteur a l’esprit tordu, en réalité, c’est plutôt bien vu et au passage j’ai pu apprendre un nouveau langage. Personnellement, j’ai fait le choix de développer à la main les exercices plutôt que simplement les lire. Je trouve qu’on se fait une idée plus précise de la pratique de cette façon. La suite est plutôt pas mal non plus puisqu’il aborde différents patterns. Des patterns de développement en TDD, de refactoring, des design patterns,…

Bref plutôt enrichissant tout ça.

Acheter ce livre

A propos de l’auteur

Bonjour, je suis Florent Lothon, manager de génération Y et l'auteur des contenus de ce site. J'y partage mes connaissances et expériences dans le domaine de la gestion de projet agile. Vous pouvez en savoir davantage sur moi et les valeurs qui m'animent, ici.

Partagez vos réflexions 2 commentaires