WHAT

Test
Driven Development

Behavior
Driven Development

Domain
Driven
Design

Behavior Driven Team

Because it's hard to develop and design
a good application

Agile

Behavior Driven Design

since 2003 mentioned by Dan North

Favor collaboration between team actors

• Use examples in order to describe the behavior of the need.
   
• Enable automation of this examples in order to drive development and having regression tests.
   
• Use useful keywords to clarify and question the needs and then ensure it achieves initial requirement.

Domain Driven Design

since 2003 mentioned by Eric Evans

Favor communication between team actors

• Use the expert's vocabulary of the domain : Customer, Business Analyst ...etc
   
• Same ubiquitous language for each team actors
   
• Reflects the main intention of the project
   
• The code is easy to understand by every-one because it uses domain words

Test Driven Design

since 2000 mentioned by Kent Beck

Favor trust between team actors

• Explore and refine business needs
   
• Implement exactly what the business needs (no more)
   
• Respond to needs with minimal complexity
   
• Improve fiability and quality and reduce fear...
   
• Increase capacity of change

WHY

Communication First

Empowered by Agile

Low quality costs money !

Deliver on time

Cases :

• Lack of information
• Gap between needs and implementation 
• Fear and no trust in the application in production
• Functionnal Bug(s)
• Technical Bug(s)
• Understanding of the need is too difficult
• Lack of communication
• Bad understanding of the business

DDD :

Help to understand the problem
without thinking of the technical solution.

BDD :

Help to describe the problem
without thinking of the technical solution.

TDD :

Help to solve the problem
through a technical solution.

WHO

Whoever cares about costs

Whoever cares about customers

Short Term And Long Term

Needs And Satisfaction

Product Owner

• Want the right product for the customer
   

• Can check before showing to the customer that the product increment suits the need and be confident

• Can focus on business domain rather than
   technical stuff

• Can check each US complies with its own behaviors description

Business Analyst

• Does not want any surprise

• Expect what is specified

• Can understand the need easily

• Can verify the product increments easily when each US is done

• Can give fast feedback  :
  Helped by continous delivery

Tester

• Want to know what to test

• Want to verify increment

• Can understand the need easily

• Can propose an improvement of the need

• Can write code that fits the US description

• Is able to prove that the product increment suits the need

Developer

• Want to know what to do

• Want to respond to the need

Developer

Tester

Business Analyst

BDD

TDD

DDD

Product Owner

Customer

Company

BUSINESS
DOMAIN

Developer

Tester

Business Analyst

Customer

Product Owner

Company

HOW

Product Spec

A user should see a responsive page with his information  

Verify that the page is present

Example :
Given a user should see this page

With BDD

Given a user
should access to his information 

Verify that a user
can access to his information

Example :
Given Tony with 1234 id who  want to access to his information corresponding to id 4321 should see his information

With DDD

Given an authenticated customer
When authorized
should access to his habitation contract
 

Verify that an authorized customer
can access to his habitation contract

Example :
Given Tony as customer with 1234 customer id who  want to access to his habitation contract with the contract number 4321 should see his habitation contract

With TDD

Test : Given an authenticated customer
When authorized
Should access to his habitation contract
 

Start writting code

With TDD

Wait ...
What is an authenticated customer ? (Improve DDD)

Wait ...
When the customer can be authorized  ? (Improve BDD)

Wait ...
How can i know that is a customer ? (Improve BDD, DDD)

Wait ...
How can i determine what is an habitation contract ?
(Improve BDD, DDD) ... etc

After response => little code

After response => little code

After response => little code

Virtuous loop

Define needs with BDD and DDD

Implement needs with BDD, TDD and DDD

Improve needs Spec

Ready to implement needs

Perfect response to the needs
regarding to the team knowledges

Agile Help

Refinement : 

Help to focus on business need and to understand it easily

Story Mapping
and colocation :

Help to share a common vision and vocabulary with every product actors

Understanding TDD

Write a failing test

Write
a code to make it pass

Make the code better
(Refactor)

DEMO

Advice

Do not Speak about
user interface

The need is first about domain

Do not trust first

• User interface
• Services
• Data
• Specifications

Know the domain

Technical thing
must be a detail

Prefer fat and strong model because it's easy to :

• Change
• Understand
• Test

Single responsability principle first

Example :

Example :

Test Functionnal Things First

• Do not test function one by one 
• Test every cases / path (no exception)
• Be smart  :
  • do not reinvent the wheel
  • sometimes you can use what you have
    already done

Test Priority

Pre-requisite

Respect on quality and resources

• Experimented Team

• Agile Team

• Collocated Team

• At least one dev member should know about :
  Agile, DDD, BDD, TDD

Verbatim

"Explication du métier au dev", J.A

"Plus de rigueur dans le découpage des US et la description des critères d’acceptation", J.A

"Moins de surprise (en terme de résultats attendus) après les DEV", J.A

"Une meilleure compréhension du besoin", G.M

"Connaissance partagée et maturité d'équipe importante", G.M

"Facilite le feed back", G.M

"Une colocalisation peut aider", G.M

"L'anticipation sur les jeux de données est essentielle", G.M

"S'accorder du temps pour la montée en compétence", G.M

"Travail plus collaboratif avec les DEV", J.A

" Moins d’anomalies pendant la phase de recette ", J.A

UseFul
Books, Links and Docs...

For Every member of the Team :

• "Domain Driven Design", Eric Evans

• "Scrum guide" (Doc)
• Lean principle 
• https://agilemanifesto.org/
• Story Mapping 
• Event storming 
• Scrum life (youtube)
• https://blog.octo.com/le-bdd/