La nouvelle ère de l’agilité : l’approche hybride TDD , DDD et BDD combinés

Partager

Cherchez-vous à mettre en œuvre un projet avec succès ? La réponse sera bien sûr que oui, mais comment faire le bon choix pour le développement de logiciels sachant que le monde digital aujourd’hui est saturé de Frameworks, de méthodologies et de processus et la plupart viennent avec la promesse d’un meilleur résultat. Mais est-ce-que réellement une seule méthode suffit ? Procure-t-elle des avantages de maintenabilité et d’évolutivité à votre projet tout en gérant sa complexité croissante ?  

La meilleure solution face à un problème pareil consiste souvent à combiner plusieurs méthodes. Chez AYMAX, notre travail se base sur l’agilité, nous avons donc une flexibilité et une marge d’innovation qui nous permet de trouver une combinaison hybride répondant parfaitement à nos besoins. Certes, le choix ne se fait pas arbitrairement. En effet, les méthodes doivent être complémentaires, et elles doivent fournir une valeur ajoutée unique qui assure des résultats productifs. Après avoir faire les recherches nécessaires, notre choix s’est fixé sur le TDD, BDD et DDD.

1. DDD

La conception pilotée par le domaine (ou DDD, de l’anglais domain-driven design), est une approche de conception qui a été introduite par Eric Evans en 2003 et se base sur deux principes :

  • La complexité du domaine métier doit se refléter dans le modèle.
  • L’accent doit être mis sur le domaine et la logique associée et non pas sur les contraintes techniques .

Nous pouvons alors considérer Le DDD comme étant une manière de communication des problèmes et leurs solutions, entre les équipes techniques et fonctionnelles. Pour se faire, nous devons connaitre les concepts clé de cette approche qui sont respectivement :

  1. Le contexte qui constitue le périmètre où un mot ou phrase a une signification ; un mot peut appartenir à un ou plusieurs contextes avec de différentes significations.
  2. Le domaine c’est la sphère (core) d’un métier pour lequel on développe l’application.
  3. Le modèle qui est une abstraction de la réalité qui décrit les concepts clés d’un domaine et utilisé pour résoudre les problèmes liés à ce domaine.
  4. Un langage ubiquitaire (Ubiquitous Language) c’est un langage de communication commun qui structuré autour du modèle du domaine métier au sein de l’équipe de développement

Parmi les objectifs de cette approche, est la familiarisation des développeurs avec le fonctionnel de sorte que le code source manifeste fortement le langage commun et donc l’émersion des concepts de domain modeling spécifiques et adaptés au cœur du domaine et la levée d’ambiguïtés.

L’avantage majeur du DDD qu’il procure en premier lieu une manière de concevoir flexible et évolutive et assure obligatoirement une communication continue tout au long du projet et donc une connaissance partagée assurant une maintenabilité, simplicité et réutilisabilité élevée grâce à l’expressivité métier donnée au code source. En second lieu, le DDD peut être associé facilement aux pratiques adoptées et éprouvées dans l’équipe chose qui nous mène à parler du BDD qui peut être combiné avec le DDD et donc c’est quoi le BDD ?

2. 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.

Conçu en 2003 par Dan North, le behavior-driven development (ou BDD) est une méthode agile qui met en avant le langage naturel et les interactions dans le processus de développement logiciel. En effet, l’équipe technique utilise le langage naturel en combinaison avec le langage du domaine du DDD afin de décrire l’objectif de leur implémentation.

Le principe du BDD est de préciser un « comportement désiré », utiliser des exemples pour le décrire (bout de code), automatiser ces exemples pour revenir avec un feedback et des tests de non-régression qui sont structuré en scénario qui permet de formaliser l’expression des besoins avec un langage commun et facilement interprétable. Les scénarios se présentent sous la forme :

Etant donné (Given) c’est une description ;
Lorsque (When) il s’agit des actions effectuées ;
Alors (Then) c’est l’étape de la vérification.

Ces scénarios sont facilement traduits en test automatisé via des Frameworks disponibles tels que Cucumber .

Après l’avoir expérimenté sur notre projet R&D MyTrackBoard, nous avons constaté que se lancer sur un process BDD est vraiment très enrichissant. Les avantages d’une telle pratique sont multiples :

  • Un développement guidé et documenté car le besoin fonctionnel devient celui qui guide le développement de l’application.
  • Une communication forte au sein de l’équipe puisque l’écriture des scénarios inclut toute l’équipe et l’expression du besoin se fait avec un langage naturel décrivant le fonctionnement réel attendu de l’application. Ce point est en commun avec la DDD vu que les règles métiers sont moins abstraites et mieux comprises en utilisant langage commun et facilement interprétable. 
  • La continuité des tests car il s’agit d’une méthodologie de travail, permettant d’écrire des tests compréhensibles à la fois par le client et par le développeur et s’intégrant directement dans la base de code.

Parlons des tests, nous ne pouvons pas parler du BDD sans passer par le TDD. Mais en réalité que représente le TDD ?

3. TDD

Encore un acronyme du type xDD ? Eh bien oui, encore un ! En fait, Ce n’est qu’au début des années 90 que sont apparus des outils permettant aux développeurs de créer leurs propres tests. Puis, dans les années 2000, le terme pilotage par les tests (« Test Driven ») a émergé. Enfin, le TDD (pour « Test Driven Development »), ou Développement Piloté par les Tests, a apparu en 2003 qui était conçu par Kent Beck, dont le principe était l’écriture des tests c’est elle qui dirige l’écriture du code source des applications, c-à-d écrire un test avant de coder par conséquent la programmation et l’amélioration du code devient continue (encore appelée refactorisation).  En effet, une démarche est créée pour mettre en place cette méthode qui se déroule en trois phases appelés RGR (aussi appelé la Mantra) comme l’indique la figure suivante :

Dans ce sens, le cycle de développement suivi en TDD est divisé en cinq étapes :

  1. Décrire un problème par l’écriture d’un test.
  2. Exécuter le test et s’assurer qu’il échoue ; vu que le code à tester n’existe pas encore.
  3. Coder juste pour assurer l’exécution réussite préalablement établi.
  4. Vérifier la réussite du test en question avec l’exécution d’autres tests.
  5. Remanier (refactor) le code ; améliorer sa qualité sans modifier le comportement, en d’autres termes en conservant les mêmes fonctionnalités.

Les processus de développement logiciel agile renforcé par le TDD sont devenus les bases d’une livraison rapide et fréquente de composants logiciels fonctionnels. Ainsi l’emploi de cette méthode assure :

  • Qualité du logiciel : Les tests tels qu’ils sont mis à profit dans TDD permettent lors de la construction des livrables :

Le logiciel ainsi est produit avec une qualité garantie justifiée par la couverture et la pertinence des tests effectués, répondant parfaitement aux besoins et conçu pour le faire avec une complexité minimale d’où une conformité aux besoins métiers.

  • Exploit des tests unitaires : D’une manière classique, les tests unitaires sont souvent remis à plus tard et ne sont effectués qu’après le codage donc ils deviennent fortement dépendants au code, chose qui pose un problème dans le cas où il existe des parties dans le code qui ne sont pas testables. Pour surmonter ce problème, le TDD nous force à écrire le code en fonction des tests tout en respectant les contraintes imposées et donc la testabilité de l’implémentation est assurée ce qui favorise d’une part un faible couplage et une forte cohésion d’autre part.
  • Absence de la régression : le cycle du TDD permet de suivre l’état instantanément du logiciel et donc détecter facilement les sources des anomalies et les éventuelles régressions d’un changement à un autre.

Après avoir déterminé les points forts de chaque méthode, et comme nous avons mentionné au début, théoriquement leur combinaison permettra d’atteindre un excellent résultat, chose qui semble être une excellente idée mais l’étape la plus cruciale est de comprendre comment utiliser ces méthodes pour assurer un rendement maximal.

Chez Aymax, Le TDD, le BDD et le DDD se complètent pour assurer la réussite d’un projet, comment ?

Pensons tout d’abord Outside-In, car avant d’écrire une ligne de code, il faut bien définir les besoins fonctionnels à travers des exemples simples, concrets et ultraprécis en se recourant au BDD. Ceci sert à illustrer donc les règles de gestion (Acceptance Criteria) à travers un langage commun parlé par tous les acteurs, qu’ils fassent partis de l’équipe métier ou bien technique.

Il est maintenant temps que DDD prenne la relève, et pensons alors Big Picture. En fait, pour commencer à développer un large projet il faut le répartir en segments et dans notre cas des domaines qui seront plus facile à gérer. Une fois, la division ou bien la répartition est terminée, chaque équipe peut se concentrer sur les fonctionnalités d’un domaine précis et le développement de l’application sera accéléré drastiquement engendrant un gain de temps.

Nous pouvons ici citer l’exemple de l’architecture microservices utilisée au sein d’AYMAX qui illustre parfaitement l’utilité du DDD : https://www.aymax.fr/pourquoi-une-architecture-de-microservices/ .

À travers ses modèles, un contexte et un langage ubiquitaire du DDD, toutes les parties impliquées doivent avoir une idée claire de la nature des problèmes et de la structure de la solution.

“A quel moment commençons-nous à écrire du code ?” la réponse est maintenant, mais avant de le faire, nous devons effectuer les tests. Alors, dans ce stade le TDD intervient en pensant Inside-Out à travers la mise en place de tests tout en implémentant le code fonctionnel, par cycle itératif, offrant ainsi non seulement une excellente conformité aux besoins métiers mais aussi une haute qualité de développement bug-free.

En adoptant une approche hybride, nous assurons que le projet sera bien conçu, documenté, testé, répondant aux besoins initialement établis et maintenable.

Article rédigé par : Hajer NEYLI — Consultante FullStack Java/Angular