Introduction
Bien que comprenant le sigle TDD, l’ATDD se rapproche plus de la méthodologie BDD. Et pourtant. L’ATDD (Acceptance Test-Driven Development) sert tout simplement (comme le TDD) à tracer la route à l’implémentation d’une fonctionnalité via les tests d’acceptations/fonctionnels.
Les 7 étapes de l’ATDD :
L’Acceptance Test-Driven Development est représentable par un cycle (très général) en 7 étapes :
- Appréhender l’User Story ou given-when-then
- Rédiger le test fonctionnel
- Tester sur une feature non codée
- Ecrire la fonctionnalité que vous souhaitez tester
- Relancer le test sur la feature
- Lorsque ça fonctionne, terminer d’écrire la feature comme vous la souhaitez
- Vérifier que l’ensemble fonctionne avec le test en utilisant donc le principe de non-regression
Si l’ATDD est souvent confondu de prime abord avec le BDD c’est tout à fait normal. Et pourtant des différences subsistent entre les deux méthodologies aux principes quasiment semblables. Tandis qu’elles imposent toutes deux la rédaction des tests avant le lancement de la programmation, l’Acceptance Test Driven Development est basé sur le fait que le développement est TOUJOURS et uniquement fait à partir des tests d’acceptation alors que le Behaviour Driven Development stipule que la programmation est basée sur le comportement souhaité. En sommes, il apparaît que l’ATDD s’intéresse bien plus que le BDD au rendu final, non seulement pour les développeurs qui travaillent sur le projet mais aussi et surtout pour les utilisateurs finaux.
La communication, un pilier de l’ATDD
C’est notamment à la mise en place des éléments fondateurs du projet que la collaboration entre les différents acteurs se fait alors que le BDD se fixe comme une méthode de tests comportementaux qui permettent de valider des spécifications par l’ingénierie et non par le désir unique de l’utilisateur final. L’UI et l’UX sont moins prépondérants dans l’application du BDD que dans l’ATDD.
De la même manière qu’avec le BDD, l’ATDD se différencie du TDD non seulement par une lettre mais aussi par le fait d’une véritable volonté de rédiger un code propre ET lisible ! Si le TDD est lui aussi effectif via les tests, il n’a pas pour volonté de créer une documentation aussi claire que l’ATDD. Ainsi, les critères de sélection sont différents entre TDD et ATDD. Pour le second, c’est en première partie du projet qu’il faut déterminer ce qui sera – ou ne sera pas – qualifié comme qualitatif. C’est la détermination de ces critères d’acception qui serviront de pattern pour le développeur et qui lui permettront d’incrémenter ces propres tests d’acceptation.
En revanche, et comme pour toute méthodologie “Agile”, il est nécessaire de prendre en compte l’ensemble des parties prenantes du projet, c’est à dire du Product Owner jusqu’aux clients finaux. Si collaboration il y a, alors la communication entre les différents utilisateurs et créateurs du développement est améliorée et c’est alors l’ensemble de la chaîne qui sait ce qu’elle a à faire et avec qui échanger lors de l’apparition de problématiques.
On peut ainsi distinguer 4 étapes dans la mise en place de l’ATDD (plus global que les 7 étapes précédemment citées).
- Communiquer dès le début du projet :
Il faut que l’ensemble des parties prenantes (PO, développeurs, users finaux) s’entretiennent sur les features à développer et la difficulté des tâches. Ensuite, on suit le format classique de l’user story. Une fois toutes les fonctionnalités expliquées, ce sont aux équipes de développeurs de spécifier les critères d’acceptation qui permettront d’effectuer et de valider les tests. - Créer et diffuser les tests
Seconde étape du processus, la phase d’implémentation des tests d’acceptation. Il est recommandé l’utilisation d’outils d’automatisation (frameworks, logiciels open-source comme Selenium, Protactor ou Watir), afin de vérifier la maintenabilité des tests et leur efficience vis-à-vis des fonctionnalités demandées. Il faut surtout que l’enchaînement se fasse de manière organique et structurée. Les tests doivent être exécutes en échec. - Développer c’est gagner !
Troisième phase du cycle et non des moindres. Le développement fait suite à l’implémentation des tests par la rédaction de leur code source. C’est la phase qui coïncide le plus avec les caractéristiques du TDD puisque c’est elle qui intègre la notion d’itérations courtes et successives. Si l’implémentation des tests est un succès, c’est gagné ! - Renseigner les utilisateurs
Presque terminé ! Tout comme la discussion était l’acte primordial du début de projet, elle se retrouve de nouveau élément essentiel à la fin. Il s’agit alors de réaliser une démonstration de votre résultat final. Cette étape peut aussi être appelée validation finale puisqu’elle permet aux développeurs, au PO et potentiellement aux users finaux de se faire une idée du produit terminé.
Vous l’aurez compris, l’ATDD donne une place importante à la collaboration et c’est donc certainement l’une des méthodologies les plus dignes de l’« Agile » en termes de suivi du bon sens puisqu’elle permet, à chaque étape, d’intégrer l’ensemble des métiers et des personnes que concerne le projet. Et, nous n’aurons de cesse de le dire, d’inclure l’expérience utilisateur et l’humain comme facteur clé de la réussite du projet. Le « vite fait-mal fait » n’a pas sa place avec l’ATDD bien que les itérations de développement soient courtes. Enfin, sa complémentarité avec le TDD se retrouve dans la recherche de satisfaction du client et dans l’écriture d’un code véritablement propre.