TDD, BDD et DDD sont des approches très complémentaires dans la réalisation d’un produit. D’une meilleure compréhension au besoin à une meilleure qualité du produit.
Que sont les approches : TDD, BDD, DDD ?
La BDD (Behavior Driven Development)
La BDD (Behavior Driven Development) est une pratique Agile créée par Dan North en 2003 qui a pour but de créer des tests fonctionnels avec un langage naturel compris de tous.
Mais ce concept va encore plus loin car il permet d’amener l’équipe de réalisation à être claire sur les besoins des utilisateurs ; en effet le « En tant que…. Afin de » souvent utilisé pour définir une user-story peut parfois amener à l’ambiguïté. Ces critères d’acceptation (que certains appellent tests d’acceptation) permettent de lever tous les doutes sur la compréhension quand ils sont bien écrit.
L’écriture de ces critères d’acceptation s’écrivent dans un langage naturel appelé Gherkin. Voici un exemple simple :
Etant donné que je suis le client sur la fiche produit
Quand je clique sur ajouter au panier sur le produit d’identifiant “255”
Et que le stock est à “3”
Alors le produit se rajoute au panier.
Chaque user-story proposera plusieurs critères d’acceptation de ce type pour définir tous les comportements possibles ; ceci concerne les cas positifs et négatifs. Pour limiter au maximum l’obsolescence future de ces tests, l’implémentation ne devrait pas y être incluse.
En écrivant en amont ces tests avec les experts métiers et les utilisateurs concernés par le besoin, l’équipe aura beaucoup plus de chance de s’assurer de répondre aux réels besoins des utilisateurs tout en respectant les éventuelles contraintes : légal, business… Je définirais cette façon de faire comme le point d’entrée optimisé pour la future réalisation des fonctionnalités.
Si vous voulez en savoir plus : BDD (Behavior Driven Development)
D’ailleurs, vous pouvez regarder la vidéo de la minute agile qui parle aussi de ce sujet :
Le DDD (Domain Driven Design)
Le DDD est une approche de conception logicielle amenée par Eric Evans en 2003 qui a pour objectif d’amener le domaine métier à être un pilier de la conception logicielle. Cette approche DDD ne vous dira pas comment « coder » votre application mais vous amènera à une conception de celle-ci à être le reflet des règles métiers.
On est toujours dans cette approche générale de rapprocher tous les acteurs de conception du produit en cassant les silos entre les différentes expertises.
Voici quelques avantages non négligeables que cette approche apporte :
- effacer toute ambiguïté possible entre métiers et équipe de réalisation
- conception logicielle privilégiant des adaptations futures simplifiées
- regressions possibles en baisse
Il faut bien comprendre qu’il est indispensable que tout type d’experts (métiers, développeurs…) doivent travailler ensemble dans cette approche.
Je ferais quelques articles très prochainement sur cette approche très populaire dans la communauté des software craftsmanship mais encore peu réellement appliqué au sein des entreprises (mais cela arrive de plus en plus). Il est vrai qu’il n’est pas simple de comprendre la DDD en seulement quelques lignes.
Bien que cette approche est très différente de la BDD que nous avons vu avant, elle est totalement complémentaire à celle-ci.
- On recueille le besoin avec les métiers (en affinant les attendus) avec le BDD
- On conçoit une application qui reflète la complexité du domaine métier avec l’aide des métiers avec l’approche DDD
Le TDD (Test Driven Development)
Le TDD (Test Driver Development) est une approche de développement logiciel qui consiste à écrire les tests unitaires d’une fonction avant d’écrire le contenu de cette fonction. C’est une pratique très connue dans le domaine de l’intégration continue.
Le but de cette pratique connue en XP, Scrum XP ou en devops est d’indiquer à quoi s’exposera le code avant même d’être écrit. Cette pratique change radicalement les concepts classiques des développeurs.
Bien que le TDD renforce la qualité des produits et limite les futures regressions, la notion de « test » n’est pas sa principale fonction. Le TDD permet principalement d’amener les développeurs à trouver une solution à une demande posée par le test.
En effet, en réalisant le test en amont, les développeurs seront guidés pour aller vers la solution attendue. Terminé les pertes de temps pour réaliser des fonctionnalités avec le risque fort d’arriver à un résultat non satisfaisant.
Si cette approche est plus axée « développement », il est également très complémentaire aux deux précédentes approches que nous avons vu.
- On recueille le besoin avec les métiers (en affinant les attendus) avec le BDD
- Nous concevons une application qui reflète la complexité du domaine métier avec l’aide des métiers avec l’approche DDD
- On consolide notre application par des tests qui diminuent les regressions futures tout en étant guidé par les attendus de chaque fonction unitairement avec le TDD
Pour en savoir plus sur le TDD : TDD (Test Driven Development)
Conclusion : TDD, BDD, DDD
Ces 3 approches qui interviennent à des niveaux différents de la conception d’un logiciel sont très complémentaires. Bien que leur maitrise demandera un investissement initial, elles sauront amener les équipes à créer des logiciels de très grande qualité.
Ce trio TDD, BDD, DDD vous permettra ainsi de :
- concevoir un logiciel qui saura évoluer sur le temps
- offrir un logiciel qui répondra réellement aux besoins
- diminuer la dette technique potentielle
- limiter les ralentissements des futures évolutions souvent dues à des systèmes de plus en plus complexes
La qualité n’a pas de prix… Elle sera surtout rentable à long terme pour l’entreprise.
Lien utile en anglais: BDD (Behavior Driven Development)
Soyez le premier à commenter