Iqnite Geneva 2013 - Conception et Test avec DDD et BDD
Pourquoi et comment concevoir et tester avec les approches Domain-Driven Design (DDD) et Behavior-Driven Development (BDD) ?
La démo est accessible à http://www.grodziski.com/iqnite/demo.mp4
is a new aircraft that reach speeds of Mach 2-2.5 Why is that important ? To be able to escape from combat ! I think a good maneuverability is a better response...
is a new aircraft that reach speeds of Mach 2-2.5 Why is that important ? To be able to escape from combat ! I think a good maneuverability is a better solution... Résultat : beaucoup d’innovations et un succès commercial inégalé jusqu’à aujourd’hui ! What ! Function Why ! Requirement
le comportement attendu • Besoin de précisions, d’exemples Définir le produit Valider le produit • Besoin d’interactivité avec le logiciel pour obtenir un feedback Point de vue développeur Point de vue métier
is the concept, [...], that you are going to specify what you are going to do, and then do it [...]. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job. » D.T. Ross in the proceedings of the NATO conference on Software Engineering, 1968 « The hardest part of the software task is arriving at a complete and consistent specification, and Much of the essence of building a program is in fact the debugging of the specification » Fred Brooks in « The Mythical Man-Month » 1975.
Développeur • Manque de précisions • Manque d’exemples • Indique parfois la structure et l’algorithme du système et non uniquement le comportement Point de vue Métier • Difficulté à passer du besoin métier au comportement du système (du quoi au comment ?) • Difficile de prévoir l’ensemble des fonctionnalités au démarrage • Difficulté à définir précisément le comportement sans interactions avec le système • Difficile de « valider » des spécifications abstraites • La validation et la spécification sont des activités dé-corrélées
tests et la conception/réalisation sont souvent réalisés par des équipes différentes • => coût d’apprentissage du domaine dupliqués • Problèmes de conception sont remontés tardivement dans la chaine de réalisation • => coût de corrections élevés • Temps qui passe • => divergence entre la spécification “papier” et le code
Besoin Permettre au client de retirer de l’argent avec sa carte bancaire de manière autonome User Story « Retirer de l’argent » En tant que client porteur de carte bancaire Je veux retirer de l’argent à un distributeur Afin de pouvoir obtenir de l’argent liquide à toute heure Scénarios et Exemples Clés Retirer de l’argent – succès - cas courant Retirer de l’argent – échec - code incorrect Retirer de l’argent – échec - solde insuffisant etc.
que mon compte a un solde de 200 € Quand je fais un retrait de 50 € avec demande de reçu Alors le distributeur me fournit des billets d’un montant de 50 € Alors mon compte a maintenant un solde de 150 € Alors je reçoit un reçu indiquant un montant de retrait de 50 € Cas d’utilisation : retrait au distributeur En tant que client Je veux faire des retraits avec une carte nominative Afin d’obtenir de l’argent liquide facilement à tout heure
que <mon compte a un solde de 200 €> Quand je fais <un retrait de 50 € avec demande de reçu> Alors < le distributeur me fournit des billets d’un montant de 50 €> Alors <Mon compte a maintenant un solde de 150 €> Alors <Je reçoit un reçu indiquant un montant de retrait de 50 €> Scénario de test : retrait trop important, solde insuffisant Etant donné que mon compte a un solde de 200 € Quand je fais un retrait de 300 € Alors le distributeur affiche un message « le retrait est refusé pour cause de solde insuffisant » Cas d’utilisation : retrait au distributeur En tant que client Je veux faire des retraits avec une carte nominative Afin d’obtenir de l’argent liquide facilement à tout heure
le système ? 1 « Quand je fais l’action… » Quelles actions sont effectuées par l’utilisateur ? Quelles données sont entrées par l’utilisateur ? 2 « Alors j’observe … » qu’observe l’utilisateur en retour de ses actions ? 3
fais <Actions> Alors <retour et état attendus> Scénario de test n : Etant donné un <Etat connu> Quand je fais <Action> Alors je constate <Retour et état attendu> ... Quand je fais <Action> Alors je constate <Retour et état attendu> User Story En tant que <Role> Je veux faire <Actions> Afin d’obtenir <Valeur ajoutée métier>
le porteur possède la carte 1234 4567 8901 2345 avec un solde de 1000 € Quand le porteur effectue un retrait de 200 EUR au DAB de Paris_Pelletier Alors il obtient 200 € en espèces Alors le DAB émet le ticket récapitulatif Alors le solde du compte est de 800 €
le porteur possède la carte 1234 4567 8901 2345 avec un solde de 1000 €" Quand le porteur effectue un retrait de 200 EUR au DAB de Paris_Pelletier" Alors il obtient 200 € en espèces" Alors le DAB émet le ticket récapitulatif" Alors le solde du compte est de 800 €"
test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function » Robert « Bob » Martin
Design (DDD) est de créer de meilleurs logiciels plus facilement en se concentrant sur le domaine métier plutôt que la technologie Le cœur du logiciel est sa capacité à traiter des problèmes liés au domaine Lorsque le domaine est complexe cela devient difficile, le DDD propose des solutions pour gérer cette complexité
est dirigée par des modèles situés dans des contextes particuliers – Le langage utilisé pour communiquer entre la technique et le métier doit être le même : ubiquitous language Des blocs de construction (building blocks) Des principes de conception : – Pour la souplesse : Supple design – Pour gérer l’effort et les priorités : Strategic design
au plus tôt Décisions de conception prises au plus tôt « Spécifications » toujours en phase avec le code Meilleure qualité de l’application t0 t1 t2 t3 Connaissance du domaine Tradi. Spec. Exec.
des scénarios d’exemples : • Given / When / Then – “Behavior-Driven Development” Conception : se concentrer sur le domaine – Collaboration avec l’expert du domaine – Interagir entre le modèle et la spec au plus tôt grâce à “Code as a Model” – Dirigée par un modèle – Validée par des scénarios – “Domain-Driven Design”