Le lab n°1 - TDD, ATDD et BDD : mais au fait c'est quoi la différence?

écrit par julien.royer publié le mardi 21 novembre 2017
En guise d'introduction, nous allons résumer la différence entre les trois méthodologies de tests que nous avons expérimentées.

La méthode TDD

Faire du TDD, c'est avant tout une pratique de développement qui s'est démocratisée ces dernières années,notamment autour de l'engouement pour l'extreme Programming. Le TDD acronyme pour Test Driven Development ou "développement piloté par les tests" est une pratique qui consiste à structurer son code en commençant par écrire les tests unitaires avant d'écrire le code source de son application. On peut traduire graphiquement le processus TDD avec le schéma suivant: Le processus de développement se déroule selon une boucle itérative constituée de cinq étapes successives :
  1. Ajouter un premier test
  2. Vérifier qu'il échoue (le code qu'il teste n'existe pas encore)
  3. Écrire juste le code suffisant pour passer le premier test
  4. Relancer le test et vérifier que cette fois ci, le test passe
  5. Continuer à améliorer le code en boucle itérative successives (étape 1 à 4) jusqu'à obtenir la fonctionnalité finale souhaitée.
Le développement TDD permet au développeur de réfléchir avant d'écrire son code. Nous nous retrouvons avec un code source mieux découpé, plus flexible et plus maintenable. En résumé, la méthodologie TDD consiste à vérifier que son code fonctionne bien, c'est à dire que l'on passe correctement chacune des boucles de tests. Finalement, c'est "écrire le code correctement" ou, en anglais "write the code right".

La méthode ATDD

Nous rajoutons un A au début de la pratique TDD et cela devient une nouvelle méthode, plus communément appelée le "développement piloté par les tests d'acceptation". L'ATDD propose d'aller un peu plus loin dans la démarche. Ici, nous allons toujours chercher à écrire un code qui fonctionne mais aussi l'écrire de la bonne façon. Pour définir cette "bonne" manière d'écrire le code source, on va se baser sur des critères d'acceptations objectifs définits conjointement très tôt dans le processus de développement. Ce sont ces critères d'acceptations qui vont faire office de ligne directrice et guider le développeur dans l'écriture de son code source. Bien sûr, cela implique que le client (les analystes ou le client final) et les développeurs collaborent étroitement et interagissent ensemble pendant la phase d'analyse et de recette. Le gain est en revanche indéniable : tout le monde comprend ce qu'il a à faire, il n'y a pas d’ambiguïté et l’ensemble de la chaîne de développement est responsabilisée. Pour mieux comprendre, on peut illustrer cette méthode par le schéma suivant : On retrouve 4 étapes majeures :
  • Discussion : Les développeurs et le client discutent ensemble d'une tâche à développer. Le client explique son besoin et l'ensemble de l'équipe détaille les différents critères d'acceptations permettant de valider objectivement cette tache.
  • Implémentation : Dans cette étape, les développeurs implémentent des tests d'acceptations. Dans cette phase, nous utilisons souvent un framework d'automatisation afin de nous assurer que les tests "d'acceptances" vérifient les critères d'acceptation et s'enchaînent correctement.
  • Développement : A partir de l'implémentation, l'équipe de développement écrit le code source des tests à proprement dit. Nous pouvons reprendre ici une approche TDD avec un développement par boucles itératives successives.
  • Démonstration : Dernière étape, nous montrons ce que nous avons réalisé, c'est-à-dire Le résultat final et les tests réalisés pour s'assurer que ce résultat est valide.
Vous l'aurez compris, l'ATDD est complémentaire de la méthode TDD. Il s'agit d'écrire le bon code ("write the right code") ; c'est-à-dire celui qui satisfait au mieux les besoins du client.

La méthode BDD

Avec la méthode BDD ou développement piloté par le comportement, nous continuons notre exploration et nous allons un peu plus loin dans la notion de collaboration entre l’équipe de développement et le client. La base de travail reste similaire à une démarche ATDD (Discussion/Implémentation/Développement/Démo) mais nous proposons ici d'orienter les tests vers la spécification plutôt que vers la technique pure et d'intégrer le client en profondeur dans la démarche de développement. Pour cela, on va s'attacher à définir des comportements à travers l'écriture de scenarii réels et testables dans la vraie vie. Ces comportements sont toujours basés sur des exemples concrets. Pour écrire les scénarii, le client intervient directement avec les développeurs pendant la phase d’implémentation. Plusieurs éléments sont alors indispensables au bon fonctionnement de cette démarche :
  • Intégration au plus tôt dans la phase de développement de toutes les parties prenantes (les utilisateurs, le client, les équipes métiers et de développement...).
  • L'utilisation d'un langage naturel compréhensible par tous souvent en anglais permettant d'écrire les scénarii de tests et les cas d'exemples ensemble.
  • L'utilisation d'un framework de tests automatisés comme Specflow par exemple qui va générer à partir de l’implémentation, les différents cas de tests pour le développeur.
  • L'utilisation de mocks (des objets simulés qui reproduisent le comportement d'objets réels) afin de simuler le code qui n'aurait pas encore été écrit.
Un schéma illustrant le processus BDD : Pour l'avoir expérimenté sur notre projet R&D, se lancer sur un process BDD est vraiment très enrichissant car :
  • Le client et le développeur travaillent main dans la main. Le client voit réellement ce qui se passe et fait partie intégrante du développement. Les équipes (métiers, développement et tests) comprennent les tenants et les aboutissants de leur travail. Tous les acteurs sont parties prenantes, communiquent ensemble et sont impliqués sur toutes les phases du projet. La chaîne de développement est responsabilisée.
  • Nous évitons ou nous atténuons les clivages habituels entre
    • Le donneur d'ordre et les exécutants
    • Les différentes équipes en charge du projet (métier, développement, test, opérationnel...)
  • Les discussions entre tous les acteurs en amont permettent de se mettre d'accord sur l'objectif à atteindre
  • L'utilisation d'un langage naturel commun permet aux acteurs de se comprendre : nous parlons de la même chose, sans ambiguïté.
  • L'utilisation et la définition de scénarii spécifiques permet de cerner l'intégralité d'une problématique. Nous recentrons les développements sur le cœur de métier du projet.
  • L'utilisation d'exemples concrets permet un meilleur compréhension du contexte métier. Finalement, nous donnons du sens à ce que nous allons développer et nous nous assurons de ne rien oublier.
  • Nous écrivons des tests qui font sens portant sur les fonctionnalités majeures du projet de manière continue. Nous diminuons drastiquement le nombre de bugs et d'erreurs car nous les traitons en amont.
  • Nous pouvons documenter très facilement son code, qui devient ainsi plus maintenable.
Bien sûr le système est un peu contraignant et nécessite une forte implication (notamment du client qui doit être très disponible) mais est ce que le jeu n'en vaut pas la chandelle?   Si cette mise en bouche vous a donné envie d'en savoir un peu plus c'est par ici :