WEBVTT

1
00:00:19.348 --> 00:00:24.531
Bonjour à toutes et à tous et bienvenue dans ce nouvel épisode du podcast PunkinDev.

2
00:00:25.891 --> 00:00:26.291
Et oui,

3
00:00:27.152 --> 00:00:28.212
vous avez vu le titre.

4
00:00:28.813 --> 00:00:30.793
TDD c'est Overkill.

5
00:00:31.774 --> 00:00:32.254
Limite,

6
00:00:32.774 --> 00:00:34.335
ça sert quasiment à rien.

7
00:00:36.236 --> 00:00:37.097
Et vous devez vous dire,

8
00:00:37.177 --> 00:00:38.459
mais il fait quoi PunkinDev,

9
00:00:38.479 --> 00:00:40.741
il a pété les plombs à dire des trucs pareils ?

10
00:00:42.603 --> 00:00:45.626
Alors si le crafteur qui est en toi s'offusque de ça,

11
00:00:46.527 --> 00:00:47.068
respire,

12
00:00:47.628 --> 00:00:48.709
ça va bien se passer.

13
00:00:50.331 --> 00:00:52.053
Si à l'inverse tu détestes tes dédés,

14
00:00:53.274 --> 00:00:53.795
respire,

15
00:00:54.676 --> 00:00:56.558
ça va peut-être pas si bien se passer.

16
00:00:58.820 --> 00:01:00.101
Reprenons déjà les bases.

17
00:01:00.501 --> 00:01:01.301
TDD c'est quoi ?

18
00:01:01.942 --> 00:01:04.523
Alors TDD j'en ai parlé il y a longtemps dans le podcast,

19
00:01:04.783 --> 00:01:06.624
mais on va quand même repartir du début.

20
00:01:07.605 --> 00:01:09.066
Comme j'ai très bien appris ma leçon,

21
00:01:09.126 --> 00:01:10.326
parce que je suis un très bon élève,

22
00:01:10.967 --> 00:01:14.048
je sais que TDD c'est Red Green Refactor.

23
00:01:14.949 --> 00:01:16.570
D'abord j'écris un test qui plante,

24
00:01:16.910 --> 00:01:17.730
la phase rouge,

25
00:01:18.231 --> 00:01:18.431
red,

26
00:01:19.131 --> 00:01:21.852
puis je code l'impleme pour faire en sorte que le test passe,

27
00:01:22.053 --> 00:01:23.533
ça c'est la phase verte.

28
00:01:24.114 --> 00:01:26.295
Et enfin j'ai tout loisir d'améliorer mon code,

29
00:01:26.295 --> 00:01:27.235
de faire du rifacto.

30
00:01:27.976 --> 00:01:28.496
Certains appellent ça.

31
00:01:28.496 --> 00:01:29.136
ça la Fuzz Blue.

32
00:01:30.057 --> 00:01:33.940
Mais je peux faire ce refacto parce que ma suite de tests m'assure que je ne vais rien casser.

33
00:01:35.962 --> 00:01:40.285
Saurez-vous noter la petite subtilité qui s'est glissée dans cette définition ?

34
00:01:41.226 --> 00:01:42.347
Sur le passage au vert,

35
00:01:42.427 --> 00:01:42.827
justement.

36
00:01:44.220 --> 00:01:48.983
Cette définition précise que l'impleme doit être en fait la plus triviale possible.

37
00:01:49.964 --> 00:01:55.688
On doit produire le code minimal qui permet de faire passer le test du rouge au vert.

38
00:01:57.289 --> 00:02:03.093
Et pour moi c'est cette petite subtilité qui change beaucoup de choses,

39
00:02:03.313 --> 00:02:04.674
qui change en fait un petit peu tout.

40
00:02:05.915 --> 00:02:07.596
C'est cet élément qui introduit,

41
00:02:07.636 --> 00:02:09.618
qui induit la notion de baby steps,

42
00:02:10.118 --> 00:02:11.939
d'incréments aussi petits que possible.

43
00:02:13.160 --> 00:02:13.680
Et sans ça,

44
00:02:14.140 --> 00:02:17.761
on ne va pas pouvoir laisser les tests piloter notre implême,

45
00:02:18.081 --> 00:02:19.762
comme TDD nous incite à le faire.

46
00:02:20.442 --> 00:02:20.722
TDD,

47
00:02:20.922 --> 00:02:21.402
pour mémoire,

48
00:02:21.462 --> 00:02:23.303
c'est Test Driven Development.

49
00:02:23.443 --> 00:02:26.384
C'est du développement piloté par les tests.

50
00:02:28.324 --> 00:02:29.184
Pour être très honnête,

51
00:02:29.965 --> 00:02:30.945
c'est cette phase qui,

52
00:02:30.985 --> 00:02:31.265
pour moi,

53
00:02:31.345 --> 00:02:33.546
est la plus difficile à apprendre de TDD.

54
00:02:35.026 --> 00:02:38.607
On peut facilement apprendre à coder des tests avant de coder des implêmes,

55
00:02:38.787 --> 00:02:40.288
sans vraiment faire du TDD.

56
00:02:42.320 --> 00:02:48.363
On peut donc finir avec un simili-TDD que certaines personnes appellent du test-first.

57
00:02:50.043 --> 00:02:54.105
Mais faire ça en ayant déjà une forte idée de l'impleme qu'on va produire après.

58
00:02:54.585 --> 00:02:58.787
Et au final un peu biaiser l'écriture de nos tests pour parvenir à cet implème.

59
00:03:00.968 --> 00:03:02.028
Pour certaines personnes,

60
00:03:02.088 --> 00:03:06.810
effectivement là on n'est pas sur du vrai TDD comme il faut le faire normalement,

61
00:03:06.910 --> 00:03:08.471
sinon on n'est pas des bons devs.

62
00:03:09.851 --> 00:03:10.332
Mais en vrai...

63
00:03:11.756 --> 00:03:17.159
Est-ce que c'est grave de ne pas faire du pur TDD by the book comme c'est précisément défini ?

64
00:03:20.141 --> 00:03:24.423
Pour les puristes qui s'étripent à savoir s'il faut faire du TDD en London ou en Chicago School,

65
00:03:24.923 --> 00:03:27.145
c'est probablement un odieux crime de lèse-majesté.

66
00:03:28.626 --> 00:03:29.086
Mais en vrai,

67
00:03:30.286 --> 00:03:30.407
non,

68
00:03:30.887 --> 00:03:31.747
je ne suis pas d'accord.

69
00:03:32.127 --> 00:03:33.168
Ça n'a rien de grave.

70
00:03:33.668 --> 00:03:36.470
C'est pas grave de ne pas faire du TDD parfaitement.

71
00:03:38.211 --> 00:03:38.971
Qu'est-ce qui est important ?

72
00:03:40.252 --> 00:03:41.532
Qu'est-ce qui compte vraiment ?

73
00:03:42.793 --> 00:03:43.293
Faire style,

74
00:03:43.513 --> 00:03:45.434
qu'on maîtrise à fond la pratique,

75
00:03:46.294 --> 00:03:47.134
plus ou moins à la mode,

76
00:03:48.335 --> 00:03:52.416
ou alors toujours essayer de délivrer le max de valeur le plus sereinement possible ?

77
00:03:54.316 --> 00:03:54.797
Pour la valeur,

78
00:03:54.817 --> 00:03:55.757
le débat est plus compliqué.

79
00:03:56.997 --> 00:03:59.158
Mais pour le côté sereinement,

80
00:04:00.458 --> 00:04:00.979
on va causer.

81
00:04:03.019 --> 00:04:04.320
Pourquoi on écrit des tests au fait ?

82
00:04:05.760 --> 00:04:06.040
Pour moi,

83
00:04:06.100 --> 00:04:06.800
écrire des tests,

84
00:04:06.820 --> 00:04:08.581
c'est juste pour se simplifier la vie.

85
00:04:09.261 --> 00:04:12.562
Pour faire en sorte de savoir que notre code fonctionne.

86
00:04:12.862 --> 00:04:13.962
Et j'appuie sur le savoir.

87
00:04:14.602 --> 00:04:16.943
Savoir plutôt qu'espérer.

88
00:04:18.503 --> 00:04:20.084
Écrire des tests automatisés,

89
00:04:20.124 --> 00:04:21.664
c'est sortir du edit and pray.

90
00:04:22.264 --> 00:04:25.425
Et basculer dans un monde factuel et serein.

91
00:04:26.946 --> 00:04:27.366
Et en vrai,

92
00:04:27.606 --> 00:04:29.006
rien qu'arriver à ce niveau-là,

93
00:04:29.146 --> 00:04:30.587
c'est déjà hyper coûteux.

94
00:04:31.347 --> 00:04:35.408
Il y a des applis legacy où il va falloir faire un paquet de travail de rifacto.

95
00:04:35.668 --> 00:04:37.809
d'archives pour pouvoir poser le moindre TU.

96
00:04:38.870 --> 00:04:39.330
Donc en soi,

97
00:04:40.410 --> 00:04:42.251
rien que le fait d'avoir des tests automatisés,

98
00:04:42.311 --> 00:04:45.033
ça peut des fois constituer un pas énorme.

99
00:04:48.614 --> 00:04:48.855
Oups.

100
00:04:50.095 --> 00:04:51.216
J'ai dit TU juste avant.

101
00:04:52.636 --> 00:04:52.796
Allez,

102
00:04:52.836 --> 00:04:53.877
une petite parenthèse vite fait.

103
00:04:54.437 --> 00:04:54.998
C'est quoi un TU ?

104
00:04:55.638 --> 00:04:55.978
Un TU,

105
00:04:56.098 --> 00:04:57.499
c'est un test unitaire.

106
00:04:57.719 --> 00:04:58.899
Merci Captain Obvious.

107
00:05:00.488 --> 00:05:00.608
Oui,

108
00:05:00.928 --> 00:05:03.270
donc ça doit tester une unité.

109
00:05:04.530 --> 00:05:05.011
On avance.

110
00:05:06.972 --> 00:05:07.652
Alors en réalité,

111
00:05:07.712 --> 00:05:10.814
toute la problématique porte sur le choix de cette unité.

112
00:05:11.214 --> 00:05:12.895
Il y a encore des gens qui font débat là-dessus.

113
00:05:12.935 --> 00:05:13.315
Pourtant,

114
00:05:14.036 --> 00:05:15.577
dans le cercle des initiés,

115
00:05:15.617 --> 00:05:15.857
tout ça,

116
00:05:15.917 --> 00:05:16.197
blabla,

117
00:05:16.697 --> 00:05:18.138
il n'y a plus trop de débat là-dessus.

118
00:05:20.199 --> 00:05:21.520
Mais dans un apprentissage,

119
00:05:22.220 --> 00:05:22.941
ça peut évoluer.

120
00:05:23.421 --> 00:05:24.662
Quand on écrit nos premiers tests,

121
00:05:24.662 --> 00:05:25.262
on se dit que l'unité...

122
00:05:26.043 --> 00:05:26.583
c'est la fonction,

123
00:05:27.243 --> 00:05:27.744
la méthode,

124
00:05:27.764 --> 00:05:28.784
ou au pire une classe.

125
00:05:30.065 --> 00:05:32.247
Je pense vraiment que la plupart des devs ont commencé par là.

126
00:05:33.308 --> 00:05:34.148
Et généralement,

127
00:05:34.208 --> 00:05:38.371
on a rapidement des soucis avec plein de tests sur une même fonction.

128
00:05:38.531 --> 00:05:39.772
Dès qu'on touche à la fonction,

129
00:05:39.832 --> 00:05:40.833
ça casse des tests,

130
00:05:40.853 --> 00:05:46.857
et souvent on désactive les tests et on abandonne jusqu'à croiser la bonne personne,

131
00:05:46.877 --> 00:05:47.458
le bon bouquin,

132
00:05:48.338 --> 00:05:49.699
qui va nous expliquer ce qu'on a loupé.

133
00:05:51.925 --> 00:05:55.748
Pour moi l'unité à prendre dans un test unitaire c'est une unité métier,

134
00:05:56.669 --> 00:05:57.289
fonctionnelle.

135
00:05:57.830 --> 00:06:08.318
Dans un TU on va valider une petite unité de comportement métier qui pourra peut-être ne tenir que dans une fonction mais peut-être et probablement plus.

136
00:06:09.639 --> 00:06:15.504
L'important c'est que la fonctionnalité reste valide et ce quelles que soient les modifications opérées sur les impléments.

137
00:06:17.566 --> 00:06:18.887
Fermons la parenthèse sur les TU.

138
00:06:20.732 --> 00:06:21.413
Donc imaginons,

139
00:06:21.914 --> 00:06:23.795
on arrive à écrire des tests unitaires,

140
00:06:24.716 --> 00:06:26.758
automatisés.

141
00:06:26.858 --> 00:06:27.399
Ça fait le taf,

142
00:06:27.499 --> 00:06:27.619
non ?

143
00:06:27.980 --> 00:06:29.641
On a des comportements validés par des tests,

144
00:06:29.661 --> 00:06:33.045
donc on peut sereinement passer d'une itération à l'autre sans crainte de tout péter.

145
00:06:34.746 --> 00:06:35.607
Alors sur le papier,

146
00:06:36.108 --> 00:06:36.288
ouais,

147
00:06:36.728 --> 00:06:37.569
ça semble parfait.

148
00:06:39.251 --> 00:06:39.992
Sauf qu'en vrai,

149
00:06:40.152 --> 00:06:40.532
tout seul,

150
00:06:40.592 --> 00:06:41.553
d'écrire des tests comme ça,

151
00:06:41.954 --> 00:06:42.574
ça suffit pas.

152
00:06:44.640 --> 00:06:49.676
Pourquoi est-ce que vous pensez qu'on se casse la tête à écrire des tests avant de coder un impléme ?

153
00:06:51.360 --> 00:06:52.480
Je vous spoil déjà la fin.

154
00:06:53.641 --> 00:06:56.842
Mais est-ce que vous avez entendu parler de ce qu'on appelle le biais de confirmation ?

155
00:06:57.762 --> 00:06:59.842
Ça aussi j'en ai causé dans un très vieil épisode.

156
00:07:00.483 --> 00:07:02.163
Mais on va refaire rapidement l'expérience.

157
00:07:02.763 --> 00:07:04.424
Imaginez je vous donne une suite de nombres,

158
00:07:04.584 --> 00:07:05.124
je sais pas moi,

159
00:07:05.344 --> 00:07:05.584
3,

160
00:07:05.704 --> 00:07:05.904
6,

161
00:07:06.004 --> 00:07:06.164
9,

162
00:07:06.844 --> 00:07:11.806
et je vous demande de me proposer des nouveaux nombres pour tenter de cerner quelles règles s'appliquent à cette suite.

163
00:07:12.906 --> 00:07:14.486
Je peux vous laisser une seconde pour y penser.

164
00:07:15.326 --> 00:07:16.387
Mais quand je dis 3,

165
00:07:16.427 --> 00:07:16.567
6,

166
00:07:16.627 --> 00:07:16.767
9,

167
00:07:16.787 --> 00:07:18.807
je pense que la plupart d'entre vous ont pensé à 12,

168
00:07:18.807 --> 00:07:19.868
15,

169
00:07:20.348 --> 00:07:20.688
18.

170
00:07:21.488 --> 00:07:24.371
pour vérifier qu'on était bien sur une suite des multiples de 3.

171
00:07:26.413 --> 00:07:27.234
Vous avez eu une idée,

172
00:07:27.854 --> 00:07:29.536
et vous avez cherché à la confirmer.

173
00:07:31.057 --> 00:07:33.319
Est-ce que c'est la meilleure façon de vérifier qu'on ne se trompe pas ?

174
00:07:34.400 --> 00:07:34.780
Eh ben non,

175
00:07:35.461 --> 00:07:36.342
c'est même la pire.

176
00:07:37.022 --> 00:07:38.924
Si vous êtes convaincu qu'on a des multiples de 3,

177
00:07:38.924 --> 00:07:41.026
la meilleure façon de savoir qu'on ne se trompe pas,

178
00:07:41.726 --> 00:07:43.608
ça consiste à échouer,

179
00:07:43.968 --> 00:07:45.890
à trouver des contre-exemples en tentant.

180
00:07:46.090 --> 00:07:46.490
je sais pas,

181
00:07:46.851 --> 00:07:47.071
10,

182
00:07:47.631 --> 00:07:48.391
658,

183
00:07:48.551 --> 00:07:48.672
pi,

184
00:07:49.012 --> 00:07:49.652
racine de 5,

185
00:07:49.812 --> 00:07:50.292
moins 12.

186
00:07:51.153 --> 00:07:54.014
Et si le moindre de ces nombres vient à valider la règle,

187
00:07:54.455 --> 00:07:56.776
et bien toute la belle croyance qu'on s'était construite avant,

188
00:07:56.936 --> 00:07:57.717
ça va s'effondrer.

189
00:07:58.437 --> 00:08:02.899
Et ça sera d'autant plus douloureux que vous aurez investi plein d'énergie pour aller dans ce sens-là.

190
00:08:04.568 --> 00:08:05.049
Pour nos tests,

191
00:08:05.049 --> 00:08:05.489
c'est pareil.

192
00:08:06.049 --> 00:08:09.592
Si vous avez écrit une implème et fait en sorte que le test passe au vert,

193
00:08:10.313 --> 00:08:10.793
a priori,

194
00:08:10.834 --> 00:08:11.494
vous allez y arriver.

195
00:08:11.854 --> 00:08:13.396
Le test va passer vert assez rapidement.

196
00:08:14.837 --> 00:08:20.282
Mais qu'est-ce qui prouve que c'est bien le comportement que vous voulez tester qui fait passer le test au vert et pas un artefact étrange ?

197
00:08:21.663 --> 00:08:21.783
Ça,

198
00:08:21.823 --> 00:08:22.243
ça arrive.

199
00:08:23.965 --> 00:08:24.846
Le biais de confirmation,

200
00:08:24.966 --> 00:08:25.466
tout le monde l'a.

201
00:08:26.307 --> 00:08:27.628
Même quand on sait qu'il existe,

202
00:08:27.948 --> 00:08:28.669
qu'on sait qu'on l'a,

203
00:08:29.369 --> 00:08:30.150
eh ben on l'a toujours.

204
00:08:30.290 --> 00:08:31.851
Il n'y a pas vraiment de médicament.

205
00:08:36.506 --> 00:08:36.726
Sauf,

206
00:08:37.747 --> 00:08:44.290
on a un outil formidable dans le dev qui nous permet de contrecarrer ce biais de confirmation.

207
00:08:46.211 --> 00:08:51.815
C'est de disposer d'un test en échec et de pouvoir constater ce qu'il fait passer au vert.

208
00:08:52.555 --> 00:08:52.935
Et ça,

209
00:08:53.756 --> 00:08:59.759
c'est une assurance que c'est bien le bout de code qu'on a produit qui permet de faire passer le test au vert et rien d'autre.

210
00:09:02.752 --> 00:09:03.973
Donc si je reprends encore une fois,

211
00:09:04.673 --> 00:09:05.634
avec ces deux éléments,

212
00:09:06.375 --> 00:09:08.056
des TU bien découplés,

213
00:09:08.496 --> 00:09:09.497
des tests écrits avant,

214
00:09:10.998 --> 00:09:14.000
on pourrait s'arrêter là qu'on serait quand même vachement tranquille.

215
00:09:15.361 --> 00:09:17.222
On rajoute un peu de rifacto pour l'hygiène,

216
00:09:18.183 --> 00:09:23.267
et nous voilà avec un simili-TDD qui fait énormément de bien à nos applis.

217
00:09:26.048 --> 00:09:26.689
Donc on aurait,

218
00:09:27.570 --> 00:09:29.353
sans faire vraiment du TDD,

219
00:09:30.334 --> 00:09:32.357
une espèce de panacée du développement logiciel ?

220
00:09:35.420 --> 00:09:35.861
Là aussi,

221
00:09:35.961 --> 00:09:36.501
il y a débat,

222
00:09:36.601 --> 00:09:37.181
mais en un sens,

223
00:09:37.241 --> 00:09:38.042
moi j'ai envie de dire,

224
00:09:38.502 --> 00:09:38.662
ouais,

225
00:09:39.002 --> 00:09:39.402
quasiment.

226
00:09:40.323 --> 00:09:42.584
Et c'est pour ça que je postule que TDD,

227
00:09:42.844 --> 00:09:43.544
c'est overkill.

228
00:09:45.205 --> 00:09:45.705
Aujourd'hui,

229
00:09:45.825 --> 00:09:49.047
si on regarde ce qui se fait en moyenne dans notre industrie,

230
00:09:50.347 --> 00:09:51.308
s'arrêter à ce stade,

231
00:09:51.348 --> 00:09:58.411
ça permet selon moi d'être déjà dans le haut du panier en termes de fiabilité et de sérénité de dev.

232
00:10:00.540 --> 00:10:01.402
Sauf qu'on a un autre biais,

233
00:10:01.423 --> 00:10:03.147
c'est qu'on n'aime pas s'arrêter de progresser.

234
00:10:03.708 --> 00:10:06.154
Et on se dit que ça serait peut-être mieux de faire du vrai TDD.

235
00:10:08.395 --> 00:10:10.916
Si vous vous souvenez ce que je disais au début de l'épisode,

236
00:10:11.096 --> 00:10:13.877
ce qui manque à ce stade en fait c'est la notion de baby steps,

237
00:10:14.557 --> 00:10:16.958
et surtout quelque part de lâcher prise.

238
00:10:18.818 --> 00:10:19.719
Il faut se connaître,

239
00:10:20.299 --> 00:10:23.420
on est formé et conditionné à penser en termes de solutions,

240
00:10:23.940 --> 00:10:24.680
d'implémentation.

241
00:10:25.741 --> 00:10:27.561
Donc quand un problème à résoudre arrive,

242
00:10:27.701 --> 00:10:30.662
on va forcément avoir des idées d'implème.

243
00:10:31.562 --> 00:10:32.043
Forcément.

244
00:10:33.763 --> 00:10:34.644
La force de TDD,

245
00:10:35.204 --> 00:10:37.526
quand on arrive à le faire un petit peu by the book,

246
00:10:37.546 --> 00:10:38.647
de manière très rigoureuse,

247
00:10:38.667 --> 00:10:41.149
c'est justement de ne pas se laisser polluer par ses idées,

248
00:10:41.710 --> 00:10:46.133
et de laisser les tests nous amener à une implême à laquelle on n'aurait pas forcément pensé avant.

249
00:10:48.455 --> 00:10:49.456
Mon spoiler final,

250
00:10:49.596 --> 00:10:51.738
c'est que c'est dur.

251
00:10:52.759 --> 00:10:54.420
C'est bigrement difficile,

252
00:10:54.560 --> 00:10:55.501
et si j'étais moins poli,

253
00:10:55.521 --> 00:10:57.182
je dirais que c'est dur sa race.

254
00:10:59.171 --> 00:11:01.893
J'ai tendance à considérer qu'à prendre les étapes jusqu'à test first,

255
00:11:01.993 --> 00:11:04.014
c'est 80 à 90% du boulot.

256
00:11:04.875 --> 00:11:06.436
Sauf que les 10-20 derniers pourcents,

257
00:11:06.436 --> 00:11:10.819
ils vont coûter 10 fois plus d'énergie que le reste pour les intégrer dans des automatismes quotidiens.

258
00:11:12.220 --> 00:11:14.001
J'irai même plus loin avec un poste de travail.

259
00:11:14.001 --> 00:11:20.167
Postulat selon lequel on ne peut pas se débarrasser seul de cette propension à faire notre design en amont.

260
00:11:21.308 --> 00:11:24.911
La meilleure solution que j'aurais aujourd'hui à proposer pour pallier à ça,

261
00:11:25.952 --> 00:11:28.034
le pair et l'ensemble programming.

262
00:11:29.055 --> 00:11:32.357
Il existe même des contraintes de kata particulièrement efficaces pour apprendre ça.

263
00:11:32.838 --> 00:11:34.739
Je pense au ping-pong per programming.

264
00:11:35.119 --> 00:11:36.620
Une personne code le premier test,

265
00:11:37.000 --> 00:11:38.501
donne le clavier à la deuxième personne,

266
00:11:38.982 --> 00:11:39.662
qui fait l'implème,

267
00:11:40.243 --> 00:11:42.184
puis code le test suivant,

268
00:11:42.284 --> 00:11:43.785
et qui repasse le clavier à l'autre.

269
00:11:44.065 --> 00:11:45.206
Et on fait un ping-pong comme ça.

270
00:11:46.707 --> 00:11:47.427
Avec cette approche,

271
00:11:47.487 --> 00:11:49.849
c'est impossible de s'accrocher à une implème prévue avant.

272
00:11:50.409 --> 00:11:52.331
On n'aura que l'implème poussée par les tests.

273
00:11:53.551 --> 00:11:54.812
Et si vous êtes d'humeur taquine,

274
00:11:54.872 --> 00:11:55.733
refaites l'exercice,

275
00:11:55.733 --> 00:11:56.674
mais en mode silencieux,

276
00:11:56.834 --> 00:11:57.934
sans explication orale,

277
00:11:58.115 --> 00:11:58.815
juste avec des tests.

278
00:11:58.815 --> 00:11:59.615
des tests et du code,

279
00:12:00.196 --> 00:12:00.816
c'est redoutable.

280
00:12:00.916 --> 00:12:01.797
Mais c'est pas facile.

281
00:12:01.957 --> 00:12:04.278
Je l'ai fait récemment et moi j'aime beaucoup.

282
00:12:05.179 --> 00:12:06.419
J'aime beaucoup ce genre de difficultés.

283
00:12:09.441 --> 00:12:09.601
Bon,

284
00:12:10.381 --> 00:12:11.162
vous l'aurez compris,

285
00:12:11.222 --> 00:12:17.665
mon but n'était pas tant de bicher sur TDD que de rappeler que c'est sincèrement difficile et que c'est ok.

286
00:12:18.146 --> 00:12:20.887
C'est pas un problème de se mettre des objectifs intermédiaires,

287
00:12:21.047 --> 00:12:21.568
raisonnables,

288
00:12:21.628 --> 00:12:22.988
en attendant de progresser plus.

289
00:12:24.790 --> 00:12:26.332
Quant au puriste du gna gna gna,

290
00:12:26.452 --> 00:12:27.273
la London School,

291
00:12:27.293 --> 00:12:28.294
la Chicago machin,

292
00:12:28.454 --> 00:12:32.419
arrêtez de faire fuir les noobs avec vos querelles de paroisses totalement stériles.

293
00:12:33.060 --> 00:12:34.902
Laissez les gens apprendre à coder des TU,

294
00:12:35.122 --> 00:12:36.083
à les automatiser,

295
00:12:37.225 --> 00:12:38.386
et ensuite à les coder avant,

296
00:12:38.606 --> 00:12:38.987
et déjà.

297
00:12:39.167 --> 00:12:39.768
ce sera ok,

298
00:12:40.249 --> 00:12:40.869
encouragez-les,

299
00:12:40.990 --> 00:12:42.612
faites-les travailler et vraiment,

300
00:12:42.972 --> 00:12:43.373
c'est cool.

301
00:12:45.296 --> 00:12:49.462
C'est donc sur cette note positive qu'il me reste à vous souhaiter une excellente semaine.

302
00:12:50.403 --> 00:12:52.967
A la prochaine pour un nouvel épisode et d'ici là,

303
00:12:53.107 --> 00:12:55.410
geekez bien et codez bien.

304
00:12:56.211 --> 00:12:56.752
PAS SAUTÉ !

305
00:12:58.434 --> 00:12:58.855
Adieu,

306
00:12:58.855 --> 00:13:00.537
respectos !

307
00:13:00.597 --> 00:13:04.402
On est qu'en 2016 !

308
00:13:04.842 --> 00:13:08.207
Il y a ensuite un problème !

309
00:13:08.587 --> 00:13:13.093
C'est ça !