Test Driven Development By Example

Florent Lothon

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.

A propos de l'auteur

Florent Lothon

Expert de terrain en gestion de projet et management d'équipe. Florent fait partie des pionniers dans l'usage des méthodes agiles sur des projets à forts enjeux en France dès 2007. Co-auteur du livre "Devenir une Entreprise Agile".

Autres livres pouvant vous intéresser :

  • Bonjour Florent

    Je viens d’acheter le livre, j’ai hâte de le lire.
    Ca fait 10 ans que je fais du TDD, et pourtant je veux m’améliorer encore et toujours !

    Bravo pour votre site, je suis aussi un grand passionné d’agilité !

    Au plaisir
    Evan

    • Merci Evan 😉

      Navré de te répondre si tardivement, j’avais un peu délaissé mon site ces derniers temps.

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
    >