ATDD by Example est un guide pratique pour qui désire une introduction rapide et concrète à “l’Acceptance Test-Driven Development”. L’auteur, Markus Gärtner, qui se définit lui-même comme un artisan développeur (“software craftsman”), partage avec nous son expérience dans le domaine de l’agilité et plus particulièrement sur les tests.

Dans son introduction, Markus nous donne une rapide présentation de ce qu’est l’ATDD et ses autres formes/noms (Behaviour Driven Development, Specification by Example, Agile Acceptance Testing, Story Testing). Il présente ensuite le plan de son livre; les 2 premières parties seront des exemples concrets avec mise en situation et la 3ème partie reprendra les grands principes de l’ATDD ainsi que les bonnes pratiques à suivre.

Le premier exemple pris est celui d’un parking d’aéroport et est écrit sous la forme d’un dialogue entre les personnes de l’équipe. Il nous présente l’objectif de l’application : le calcul des coûts de parking pour un usager de l’aéroport. Le parking est partagé en trois zones: courte durée, longue durée et parking avec voiturier. L’équipe est composé d’un développeur “senior”, d’un développeur “junior”, d’un testeur et d’un représentant client. Voilà pour le contexte.
Dans ce premier chapitre, on apprend ce qu’est un “Specification Workshop” : un atelier de spécification entre l’équipe de développement et le représentant client. C’est la pierre angulaire de ce chapitre. C’est dans cette réunion que l’équipe va récolter le besoin client en mettant par écrit des exemples de fonctionnement de l’horodateur du parking. Ainsi, l’équipe peut se faire une première idée assez claire du rôle que devra remplir l’application et soulever les doutes et les erreurs de compréhension directement avec le représentant client.
Une fois les exemples décrits et épurés du superflu, le testeur peut commencer à rentrer ces exemples dans Cucumber et ainsi décrire sa première “feature”. Lorsque il arrive au bout de ses connaissances techniques, il propose une séance de “pair programming” avec le développeur afin d’automatiser le premier jeu de tests. Une fois ceci fait, le testeur peut ajouter seul les autres exemples.
J’ai bien aimé ce chapitre, rapide à lire et bourré de lignes de code qui plongent bien dans l’ambiance. On découvre Cucumber et comment faire émerger naturellement l’API de son application en s’assurant que les tests restent suffisamment découplés.

Le deuxième chapitre présente un exemple de conception d’un feu tricolore. Cette fois, l’équipe de développement est constitué de l’auteur et du lecteur, le style est plus direct. Ce chapitre est un peu moins agréable à lire, les différents états du feu tricolore n’aide pas (“Red”, “Red-Yellow”, “Yellow”).
Le principal intérêt de ce chapitre est de nous présenter Fitnesse en action et il a le mérite de le faire de façon très explicite. Ainsi on fait le tour des fonctionnalités de ce logiciel qui met l’accent sur la collaboration de part son côté wiki et mise tout sur les tables (décision, scénario, …) pour modéliser les tests. C’est un outil qui semble puissant malgré son côté esthétique rustique.

Le dernier chapitre présente une forme plus classique et l’auteur nous expose les bonnes pratiques et les astuces qu’il a su tirer de son expérience. Il nous rappelle qu’il faut accorder autant d’importance au code des tests qu’au code de l’application et nous montre qu’il est possible de faire du TDD sur l’écriture de ce code là. Il revient aussi sur l’importance de tester les conditions aux limites du domaine (plus petite valeur, plus grande, etc) ainsi que de garder un temps d’exécution raisonnable pour les tests sous peine de les voir prendre la poussière.