Présentation sur le TDD à l'UQAM le 22 mars 2018.

1. @codingpartner
Développement piloté par
les tests (TDD)
1

2. @ffalardeau
Développement piloté par
les tests (TDD)
2

3. Le logiciel propulse nos vies
3

4. Il est partout autour de nous
4

5. … et les erreurs coûtent cher
5

6. Tout va bien
6

7. La pression est sur le développeur
7

8. La pression est sur le développeur
8

9. Aussi bien aller jouer
9

10. Diagramme d’influence
10

11. Diagramme d’influence
11

12. Voici comment on reste zen !
12

13. Développement piloté par les tests
13

14. Diagramme d’influence
14

15. Le plan !
● Qu’est-ce qu’un test ?
● Pourquoi on automatise les tests ?
● Comment écrire un bon test !
● Pourquoi commencer par les tests ?
● Retour d’expérience
15

16. Le plan !
● Qu’est-ce qu’un test ?
● Pourquoi on automatise les tests ?
● On écrit un test
● Pourquoi commencer par les tests ?
● Retour d’expérience
16

17. Un nom
17

18. Une attente
18

19. Un comportement observé
19

20. Le résultat
20

21. Pourquoi on test ? 2 axes
“Are we building the right product ?”
“Are we building the product right ?”
- Dr. Barry W. Boehm
21

22. Catégorisation des tests
22

23. Les 2 types
23

24. Exemple de test écrit avec le client
Feature: Produce a single child file
Background:
Given a child registered with:
|first name |George |
|last name |Orwell |
|birth date |2007-03-23 |
|bottle |no |
|allergies |peanuts |
Scenario: Produce a basic child file
When I consult "George" "Orwell"'s file
And I see that his name is "George" "Orwell"
And I see that his birth date is "23 March 2007"
And I see that he does not expects a bottle
And I see that he is allergic to peanuts
24

25. Le plan !
● Qu’est-ce qu’un test ?
● Pourquoi on automatise les tests ?
● Comment écrire un bon test !
● Pourquoi commencer par les tests ?
25

26. Parce que c’est rapide !
26

27. 27

28. WHY: Rapidité !
28

29. Pour réhumaniser le rôle de testeur
”Manual testing is immoral.
Not only is it high stress,
tedious, and error prone it’s
just wrong to turn humans into
machines.” - Uncle Bob, Robert C Martin
29

30. Mais aussi pour ...
● Ne pas causer de régression
30

31. Mais aussi pour ...
● Livrer continuellement à
un rythme stable
31

32. Le plan !
● Qu’est-ce qu’un test ?
● Pourquoi on test ?
● On écrit un test
● Pourquoi commencer par les tests ?
● Retour d’expérience
32

33. Cycle du TDD
Faire passer
le test
Refactoriser
Écrire un
test qui
échoue
33

34. Jouons au ping pong
34

35. Jouons au ping pong
Francis Nicholas
35

36. Rouge
36

37. Rouge
37

38. Rouge ?
38

39. On regarde le test échouer
39

40. Rouge
40

41. Rouge
41

42. Vert
42

43. Rouge
43

44. Rouge
44

45. Vert
45

46. Cycle du TDD
Faire passer
le test
Refactoriser
Écrire un
test qui
échoue
46

47. Cycle du TDD
47

48. Que faut-il faut changer?
48

49. Bleu
49

50. Bleu
50

51. 2e ronde
Francis Nicholas
51

52. Rouge
52

53. Rouge
53

54. PING !
54

55. PONG !!
55

56. Bleu - Amélioration ?
56

57. PING !
57

58. PONG !
58

59. Bleu
59

60. Bleu
60

61. Bleu
61

62. Bleu
62

63. Bleu
63

64. Bleu
64

65. On nettoie continuellement
65

66. PING !
66

67. Final PONG !
67

68. Qui dit mieux ?
68

69. Comment écrire le premier test
• Ne soyez pas trop gourmand (petit pas)
• Choisir quelque chose qui va passer au vert
rapidement
Par exemple :
▪ Une opération sans effet (+ 0, * 0)
69

70. Comment choisir le prochain test
• Un test qui va vous rapproche de la
fonctionnalité souhaité
• Un test que vous êtes confiant de savoir faire
passer rapidement
70

71. Lignes directrices
• Viser à faire passer les tests le plus tôt possible
• Ne jamais passer outre l’étape de refactoring
• Programmer avec le but de partager vos
intentions
71

72. Le plan !
● Qu’est-ce qu’un test ?
● Pourquoi on test ?
● On écrit un test
● Pourquoi commencer par les tests ?
● Retour d’expérience
72

73. Pourquoi commencer par les tests ?
● Couverture de test complète (haut niveau de
confiance)
● Garde le code propre continuellement (donc
facilement maintenable)
● Influence le design du code
73

74. Le plan !
● Qu’est-ce qu’un test ?
● Pourquoi on test ?
● On écrit un test
● Pourquoi commencer par les tests ?
● Retour d’expérience
74

75. Les pièges à éviter(pitfalls)
75

76. La folie des tests d’intégration
76

77. Un cas “simple”
Validation des achats d’une minuscule boutique.
● 3 langues
● 12 devises
● 10 modes de paiements
● 10 items à vendre
En intégration: 3*12*10*10 = 3600 cas des tests
En isolation : 3+12+10+10 = 35 cas de tests.
77

78. Mock, Stubs, Fakes, Dummies, etc
78

79. Test Doubles ≈ Stunt Doubles
79

80. Exemple de la bibliothèque
80

81. On écrit un double
81

82. Un test complet
82

83. Une pratique qui est encore débattue
“Je n’ai pas besoin de test parce que je
n’écris pas de bug ...”
“Nous avons essayé le TDD, mais ça
ne fonctionne pas ...”
83

84. On doit repousser les limites de
l’automatisation
84

85. Les autres types de tests
■ Tests exploratoires
■ Tests de caractérisation
■ Tests A/B
■ Tests de charge
■ Tests d’utilisabilité
■ Tests de performance
■ ….
85

86. Une histoire
86

87. … vers la tranquilité d’esprit
87

88. Tranquilité d’esprit
88

89. Merci !
Des questions ?
@codingpartner
@ffalardeau
89

90. Bonus !
@codingpartner
@ffalardeau
90
Demandez-nous l’histoire des millions de raptor !

91. 91
Références
● Test Driven Development(livre) : https://www.amazon.ca/Test-Driven-Development-Kent-Beck/dp/0321146530
● Automatiser les tests à tous les niveaux: http://www.slideshare.net/vtence/confoo-2012-kata
● Le cas de Volkswagen(James liang)
https://www.nytimes.com/2017/08/25/business/volkswagen-engineer-prison-diesel-cheating.html
● TDD with Acceptance Tests and Unit Tests:
https://sites.google.com/site/unclebobconsultingllc/tdd-with-acceptance-tests-and-unit-tests
● Guidelines for validating and verifying software:
http://csse.usc.edu/csse/TECHRPTS/1979/usccse79-501/usccse79-501.pdf
● Is TDD dead ? http://martinfowler.com/articles/is-tdd-dead/
● Automating angry birds: https://www.youtube.com/watch?v=M1G45xkFuU0
● Justin Searls reality is expensive :
https://speakerdeck.com/searls/reality-is-expensive-a-better-way-of-thinking-about-mock-objects
● Intregration tests are a scam: http://www.jbrains.ca/series/integrated-tests-are-a-scam
● RailsConf 2015 keynote(when the wind blows, I sleep at night) https://www.youtube.com/watch?v=aApmOZwdPqA
● Code Smells: http://c2.com/cgi/wiki?CodeSmell
● Twitter: https://twitter.com/codingpartner

92. 92
Matériel supplémentaire
● Test Driven Development(livre) : https://www.amazon.ca/Test-Driven-Development-Kent-Beck/dp/0321146530
● Références sur le TDD: https://github.com/testdouble/contributing-tests/wiki/Test-Driven-Development
● Reality is expensive(mocks, stubs,)
https://speakerdeck.com/searls/reality-is-expensive-a-better-way-of-thinking-about-mock-objects
● Test d’intégrations et l’implication du QA
https://sites.google.com/site/unclebobconsultingllc/tdd-with-acceptance-tests-and-unit-tests
● Not just code monkeys(Martin Fowler sur le professionnalisme) https://www.youtube.com/watch?v=4E3xfR6IBII