Le document aborde la méthodologie BDD (Behavior Driven Development) en se concentrant sur son utilisation pour les tests d'acceptation et la communication avec les parties prenantes. Il souligne les erreurs courantes et les idées reçues autour de BDD, ainsi que l'importance de la structure des tests pour faciliter leur compréhension. Enfin, il met en avant les bénéfices observables de cette approche et la nécessité d'un code de qualité pour garantir l'efficacité des tests.

1. dans le flux du
BDD
Guillaume Saint Etienne
@guillaume_agile
Varian Medical Systems

2. ATTENTION

3. MISE AU POINT

7. TDD/BDD
is a
design activity
Kerry Buckley

10. le test manuel est …
http://blog.objectmentor.com/articles/2007/10/17/tdd-with-
acceptance-tests-and-unit-tests

12. mais il faut apprendre
idée: prenez un coach ;)

13. goOgle est mon ennemi
• Le TOP 50 des résultats pour « BDD » (en
français)
– Exemples simplistes et enfantins
– Pas représentatifs d’un vrai projet logiciel
– Pas de vrai retour d’expérience
– Articles sur BDD = ATDD (Acceptance testing /
test d’IHM)

15. Exception!
• Il faut rendre à César ce qui est à Pierre Irrmann
• http://www.arolla.fr/blog/2012/09/bdd-et-
specflow-pour-des-tests-plus-lisibles/
• « Gherkin pour écrire des tests en langage
naturel ».
• « Lorsqu’on développe en BDD, les tests sont
écrits pour tester des fonctionnalités et des
exemples précis de comportements. »

17. Parcours empirique

18. Ce qu’on voit en 1er
• GHERKIN / CUCUMBER
–Given
–When
–Then

19. Don’t misuse it!

20. Ce que m’apporte la forme BDD
T.U. classique T.U. Behavioriste
• ARRANGE • GIVEN
• ACT • WHEN
• ASSERT • THEN

21. Organisation du BDD
Librairies
Features
Scenarios
Steps
••Given
Given
••When
When
••Then
Then

22. Ce qui est trompeur

23. La puce à l’oreille
• La section « Feature » dans Gherkin
– In order to
– As a
– I want to
…ne sert à rien!!!!
Elle n’est pas compilée et donc pas « exécutée »


24. Auteur: Brian Marick

25. Tester c’est comprendre
• du latin « comprehensio »1, de « cum », avec,
et « prehendere », prendre: action de saisir
ensemble ou de prendre avec soi

27. DEBUG BDD

28. BDD = Test Comportementaliste

29. Idées reçues sur le BDD
• You want to do acceptance testing rather than
unit testing.
• You want to use it as a communication tool
with the stake holder.
• You want to do large scale tests rather than
granular tests.
• You want non-technical people to write the
tests.
http://gojko.net/2012/06/18/bdd-busting-the-myths/ [Gojko Adzic]
http://stackoverflow.com/questions/2238176/using-fitnesse-rather-than-nunit

30. You want to do acceptance testing rather
than unit testing.

31. You want to do acceptance testing rather
than unit testing.

32. You want to do acceptance testing rather
than unit testing.
•TDD is excellent

33. You want to do acceptance testing rather
than unit testing.
•TDD is the only way to be agile
•BDD is no more than TDD

34. You want to do acceptance testing rather
than unit testing.
•TDD is the only way to be agile
•BDD is no more than TDD
•BDD is first doing « unit » testing

35. You want to do acceptance testing rather
than unit testing.
•TDD is the only way to be agile
•BDD is no more than TDD
•BDD is first doing « unit » testing
•A «non-unit » test is a scam!
– Test only one thing at a time

36. You want to use it as a communication tool with
the stake holder.

37. You want to use it as a communication tool with
the stake holder.
First, use it as a communication with yourself

38. You want to use it as a communication tool with
the stake holder.
First, use it as a communication with yourself
…
then your team

39. You want to use it as a communication tool with
the stake holder.
First, use it as a communication with yourself
…
then your team
…
then (maybe) the stakeholder or the users.

40. You want to do large scale tests rather than
granular tests.

41. You want to do large scale tests rather than
granular tests.

42. You want to do large scale tests rather than
granular tests.
http://www.jbrains.ca/permalink/integrated-
tests-are-a-scam-part-1

43. Why integrated tests are a scam!
• I use the term integrated
test to mean any test
whose result (pass or
fail) depends on the
correctness of the
implementation of more
than one piece of non-
trivial behavior.
– J. B. Rainsberger

44. You want non-technical people to write the
tests.

45. You want non-technical people to write the
tests.

46. You want non-technical people to write the
tests.
•I wish I could …

47. You want non-technical people to write the
tests.
•I wish I could …
•Be pragmatic!

48. You want non-technical people to write the
tests.
•I wish I could …
•Be pragmatic!
•Maybe in the future …

49. Bref, j’ai fait du BDD
• Je passe à une description textuelle
• Exemple!

50. Bref, j’ai fait du BDD
Given I initialize the reader
And jouvre le dossier patient '1'
When je veux lire 'nom'
Then I dont have error
And jobtient une valeur 'Nom 1'

51. Et si? Je n’avais pas fait du BDD

52. DRY
• Mes tests aussi !
• Refactoring
• Les Steps Given/When/Then sont une façon
de « DRY »
• Puissance (et pièges) des expressions
régulières.
• Exemple…

53. Given I initialize the reader
And jouvre le dossier patient '1'
When je veux lire 'nom'
Then I dont have error
And jobtient une valeur 'Nom 1‘
Given I initialize the reader
And jouvre le dossier patient '1'
When je veux lire 'nais'
Then I dont have error
And jobtient une valeur '2/1/1973'

54. L’envers du décors: les Steps

55. Given I initialize the reader
And jouvre le dossier patient '1'
When je veux lire 'nom'
Then I dont have error
And jobtient une valeur 'Nom 1‘
Given I initialize the reader
And jouvre le dossier patient '1'
When je veux lire 'nais'
Then I dont have error
And jobtient une valeur '2/1/1973'
Given I initialize the reader
And jouvre le dossier patient 'F2'
And the log system is initialized with the LogWatch configur
ation
When I read ‘droits' as a Numeric
Then I have an error
And the previous log messages contains: The field 'droits' co
uldn't be read as a Decimal

56. Exemple de refactoring
• On fini par gagner énormément de temps
• Fini le copier/coller… dans le code !
• Donc fini les erreurs…. sur le code (technique)
des tests!
• Exemple!

57. 1 Feature

58. 1 Feature

59. Les Tables Specflow

60. Looks like Fitnesse (a bit)

62. Refactoring en BDD
• Nécessité de créer des Steps efficaces
• Ils sont exécutables, donc il y a du code
derrière.
• Même qualité du code des steps que du reste
du code.
• Ré-utilisables
– Then I dont have error

63. Les outils incontournables
– Dummies
– Fake
– Mocks
– Stub
– Espions / Spies
– Inversion de contrôle / Injection de dépendance
– Helpers
– … comme dans le TDD après tout!

64. Fake / Substituts
• De faux objets ayant un comportement
similaire à l’objet réel, mais d’une façon
simplifiée.
• Il n’agit pas comme un point de contrôle, mais
permet d’accélérer l’exécution des tests.
• Par exemple en remplaçant l’accès à la base
de données par des données dans un fichier
ou en mémoire.

65. Fake
• « Doublure » qui fait comme l’original
DB
ORM 4
Test
Db 4
File Object

67. Mocks
• Une « leurre » mais pas besoin d’écrire son
code « interne »
• Juste décrire ce que l’on attend de lui

68. Mock
• Le Mock se contente de bien se « comporter ».
• Simulation (Setup)
• Vérification du comportement attendu
(optionnelle).

69. outillage contrat
S.U.T.
comportement attendu

70. Stubs
• Similaires aux MOCKs
• La différence principale vient du fait qu’avec
le Stub on vérifie l’état de l’objet alors
qu’avec le Mock on en vérifie le
comportement (les interactions).
• http://bruno-orsier.developpez.com/mocks-
arent-stubs

71. Refactoring steps with helpers
• Une syntaxe pour accéder aux objets (C# 3.5)
• Sans:
– When je lis le champs ‘City’ dans la 1e adresse du patient en cours
And je lis le champs ‘Type’ dans la 1e adresse du patient en cours
And je lis le champs ‘Type’ dans la 2e adresse du patient en cours
And je lis le champs ‘Type’ dans la 3e adresse du patient en cours
• Avec:

72. Au final, qu’est ce que je teste?
• SUT / SCT : System Under Test / Système en
Cours de Test
• L’Isolation des tests est indispensable (1
problème à la fois)
• Impossible de se passer des doublures.
• Un exemple avec les Spies / Espions

73. Single Responsibility

74. Chainage des vérifications
• Pas besoin de tests automatisé intégrés.
• Si tous les mécanismes vu précédemment
sont en place.
• Néanmoins, comment en être sûr?

75. S.O.L.I.D.
• Single responsibility principle
– the notion that an object should have only a single
responsibility.
• Liskov substitution principle
– the notion that “objects in a program should be
replaceable with instances of their subtypes
without altering the correctness of that program”
• Interface segregation principle
– the notion that “many client specific interfaces
are better than one general purpose interface

76. Si mon code est SOLID
• Alors mes tests doivent l’être aussi

77. Les CONTRATS sont la clé

79. Vérification automatique
• => Outil de couverture de code.
• Néanmoins difficile d’avoir 100% (erreurs de
l’outil, code inatteignable)
• Donne une très bonne mesure de
l’amélioration de la couverture par les tests.

80. Autres vérifications à faire
• Complétude des tests
• Les « fakes » doivent être testés à leur tour.
• Parcours et vérifications auto. des interfaces:
– Si une doublure (spy/mock/stub) se fait passer
pour une interface, et qu’on n’en trouve pas une
implémentation qui ne soit pas couverte à 100%
par d’autres tests (eux même en parfaite
isolation), alors c’est un échec!
– À inventer!

81. Tests devenus inutiles: UI
Patterns: HUMBLE DIALOG, VISITOR

82. Tester à partir des UI?

83. Test the User Interface?
• « Tests »
Exploratoires
(manuels)
– Si Erreurs
détectées:
• 5% pb de config
• 10% coquilles
• 10% I/O - Sys
• 75 % manque de
tests

84. Dans le flux
L’HEURE DU BILAN

85. Avant le BDD

86. Après (dans le flux)

87. Ecriture du test: 5 à 30min

88. Steps
• Écriture: 5mn à 2h

89. Steps
• Refactoring: 1/2 à 1 journée

90. BILAN
La question n'est pas: combien
je gagne à faire des tests?
Mais,
combien je perd à chaque bug
en prod. #atmrs2012

91. Summary
01/06/2010 10/10/2012 - 1:39:45 PM
8 Applications livrées (+ 6 logiciels d’installation)
Tests running (2x day): 1564, Failures: 0, Inconclusive: 0, Time: 2158 seconds
167 Given, 183 When, 209 Then
STEPS: 44 R. --- , 77 R.---- , 73 R.
( 26% , 42% , 35%)
Efficacité moyenne 1 groupe de steps couvre 10 scénarios
« Manual » LOC of tests/specs: 12557 / 176595 ( 14%) source monitor
Source Files: 460 (comptage par OpenCover)
Coverage: 74.5% (15% UI 10% autre non couvert)
Covered lines: 9818 (comptage par OpenCover)
Coverable lines: 13161 (comptage par OpenCover)
Total SLOC Executed in tests: 48248 (comptage par OpenCover)

92. BÉNÉFICES OBSERVABLES

93. Charge de travail effective
• Nombre de bugs déclarés en exploration et
après livraison:
– 1ere année: 51
– 2ème année: 27
• Nombre de WorkItems (User Needs, Design
Quality)
– 1ere année: 98
– 2ème année: 100

94. Les tests peuvent être lus
• Ce n’est (presque) plus du code, c’est du
texte!!
• On change de perspective (passer de
l’impératif au descriptif).
• Je peux échanger avec mon équipe plus vite.
• Quelqu’un de non technique pourrait-il les
comprendre? Les écrire ?

95. Mais on est encore très loin du
langage naturel
• P.O et skateholders ne comprennent (pour
l’instant) pas tout.

96. PAG
GAP
https://docs.google.com/viewer?url=http%3A%2F%2Fwww.scrumalliance.org%2Fsystem%2Fslides%2F118%2Foriginal
%2FChristianHossa_SpecificationByExampleWithGherkin.pdf%3F1349824954

97. Qu'est ce que mon test raconte?
• Un scénario.
• Même s’il revêt une réalité technique, le
comportement devrait pouvoir être compris
et approuvé par quelqu’un de logique.
• Il ne doit cibler qu’une chose à la fois
(isolation).

98. MIEUX RACONTER
• Etre rigoureux à l’écriture des Steps
• Se conformer au Domaine (Domain Language)
• Faire du Domain Driven Design précisément
• Tests qui resteront techniques et ceux qui
seront plus proches du fonctionnel
• Masquer la technique tout en permettant une
bonne réutilisation des steps (!)

99. Est ce suffisant pour faire
une documentation?

100. Souvent!
• Si c’est bien raconté, oui pour spécifications.
• Doc Technique = OUI ! SI! YES ! JA ! DA!
• Pèsera autant qu’un lourd cahier de tests.
• On a gagné des semaines (voir des mois)
hommes de travail de rédaction et de
vérifications.
• Export automatique des fichiers Specflow ->
Html, Word, Pdf.

101. Décrire
Descriptif n’est pas Impératif

102. C’est s’intéresser à l’essentiel
• On ne voit bien qu'avec le test. L'essentiel est
invisible pour les yeux.
Antoine de Saint-Test

103. Tests that saves faith

104. Références

107. Pardon
• à Antoine de Saint-Exupéry
à relire (souvent)

108. BDD dans le flux
2e partie
Du Mythe à la réalité

109. TOUT POUR FACILITER LES TESTS

110. Changement de vision

111. Penser le comportement
Les vertus de
l’abstraction

112. Concevoir un comportement
• C’est penser en terme FONCTIONNELS

113. Design émergeant

114. Une affaire de style

115. Changement de style

116. • the system can’t neatly be tested with automated test
suites because part of the logic is dependent on
often-changing visual details
• http://alistair.cockburn.us/Hexagonal+architecture

117. La gravité

118. Dépendances fatales

119. Modèle sans gravité

120. Domain Driven Design
• C’est le meilleur moyen
d’être proche du domaine
métier de votre client
• Exemple (description BDD et
objet métier)

121. Le Domaine comme modèle
agnostique entre les composants

122. Ce que le Domaine n’est pas!
• Gestion des états => 
• Stateless => 

123. Ce que le domaine n’est pas!

124. Polyglot Data
• Le meilleur moyen d’être Data Storage
Agnostic
• Ce n’est plus le DBA qui commande
• SQL / NoSQL ?
• La persistance est un plus, voila tout.
• Exemple: le FakeStorer dans les tests

125. Incidences sur le code
1. Ecrire des Interfaces qui décrivent (abstraire)
ce que les tests vont spécifier dans des
scénarios mettant en évidence la valeur
ajoutée du comportement choisi.
2. Ecrire l’implémentation ensuite.
3. L’intégration continue vérifie tout
automatiquement => non régression.

126. Responsabiliser le code
• Isolation = Une seule responsabilité
Tester c’est apprivoiser.
• « Tu deviens responsable pour toujours de ce
que tu as testé »
Antoine de Saint-Test

127. Toujours plus fluide
• Le style change
• On devient plus « fluent »
• Le code se lit (presque) comme une phrase en
langage naturel
• On se rapproche de la programmation
fonctionnelle (sans changer de langage)
• Fluent API + lambda expressions = le chainon
manquant?

128. En Pratique
• des DOJOS pour montrer que bien tester en
1er, et tester par le comportement induit un
changement de vision dans le design du
logiciel
• Une mise en œuvre des tests et du code par la
simplicité, la rigueur et l’efficacité
• des exemples bientôt sur mon site
http://www.dotnetguru2.org/gse/

129. LES TESTS D’INTEGRATION SONT ILS
UTILES?

130. Comment on a tuer l’intégration
• Créez (ou utilisez) un mécanisme d’intégration
automatique
• Testez le!
• => plus besoin de tester en intégration
• Ajoutez tous les tests qu’il faut pour renforcer
l’intégrité du tout.
• Est-ce une bonne chose?

131. Du mythe…

132. A la réalité

133. En pratique
UN ŒIL SUR LES ESPIONS

136. S.U.T
Vérification de
comportement
en parfaite
isolation

138. EST ES?
BIENT
T-IL S
SON

139. Les pièges à éviter
• Dire « comment » au lieu de « quoi »
• Ne pas laisser transparaitre le « software
design »
• Le « software design » devrait se fondre dans
les spécifications et devenir naturel
• Ne pas se laisser enfermer dans les détails
• Ne pas tout tester en même temps (bis
répetita)

140. Pièges (Suite)
• Garder les tests parlants… (pour qui?)
• Ne pas sur-spécifier (YAGNI sur les tests)
• La partie setup/Given devrait rester simple
• Utiliser un « ubiquitous languange »
• Ne retardez pas l’usage des doublures,
injection de dépendance et autres assistants
• Ne pas sous-estimez votre code « assistant »
(testez les aussi bien)
• Introduire une part de travail manuel

141. (suite)
• Se baser sur des données pré-existantes(!!)
• Ne pas être certain que chaque test soit
idempotent.
• Perdre du sens par soucis de concision
(masquer la réaliter au lieu de la simplifier)
• L’endettement (on fini toujours par payer, et
les taux augmentent avec le temps)

142. Trucs
• Commencer petit
• Progresser à son rythme
• Refactorer régulièrement
• Le temps est votre allié
DRY! KISS! YAGNI! SOLID!

143. Tests that saves faith