Romuald, notre CTO (et Génie du développement Back-End) s'est mis à la portée de tous en vulgarisant le fonctionnement des tests unitaires et des tests d'intégration. Même les non-techs savent désormais gérer les complexités cyclomatiques !

1. www.appstud.com
AppTalk
Tests et KPI(s) QA
Quoi, Pourquoi, Comment ?
Romuald Ribas - CTO
1

2. C’est quoi un test ?
11
2

3. Une histoire de systèmes11
3
Application de tests sur un système
donné.
Ici, une machine a café.
- On appuie sur le bouton bleu
- Un café est produit

4. Une histoire de systèmes11
4
Conception d’un robot pour tester la
fonctionnalité de la machine.
- Le robot appuie sur le bouton
- Il vérifie que le contenu dans la tasse
est bien du café

5. Une histoire de systèmes11
5
Appuie sur le
bouton
Produit du café
Vérification que
la tasse
contient du
café

6. Une histoire de systèmes11
6
Appuie sur le
bouton
Produit du THÉ
Vérification que
la tasse
contient du
café

7. Une histoire de systèmes11
7
Félicitation pour votre premier test unitaire !
“vérifier le bon fonctionnement d'une partie
précise d'une unité ou module”
Maintenant, vous pourrez facilement valider que
le bouton de la machine, quand on appuie
dessus, produit bien du café.

8. Une histoire de systèmes11
8
Plusieurs problèmes peuvent survenir:
- La machine n’a plus d’eau - Système de réservoir à eau
- La machine n’a plus de grain - Système de réservoir à grain
Le test unitaire valide une fonctionnalité, mais ne tient pas compte des
autres paramètres.
C’est pour ça qu’il existe des tests d’intégration.
Pour cela, on va créer un autre robot, plus complexe, qui mélange et
teste que ces différents systèmes réservoirs fonctionnent bien ensemble

9. Une histoire de systèmes11
9
Robot d’intégration (iRobot)
- Le robot vide le réservoir d’eau
- Appuie sur le bouton pour servir un
café
- La machine doit signaler qu’il lui
manque de l’eau

10. Une histoire de systèmes11
10
Vide le réservoir et
appuie sur le
bouton
Je ne peux pas
travailler: Réservoir
vide
Vérification que la
machine détecte bien
le réservoir vide suite
à la pression sur le
bouton

11. Pourquoi ?
11
11
“dans le test d’intégration, chacun des modules indépendants du logiciel est
assemblé et testé dans l’ensemble.”
- Test unitaire = On branche la machine directement à l’eau courante pour
ne pas tester la fonctionnalité “Réservoir”
- Test intégration = On branche le vrai réservoir à la machine et on teste que
le réservoir et le bouton fonctionnent bien ensemble.

12. Comment
12
11

13. Couverture des tests
12
1
3

14. Couverture
14
11
Robot “Servietsky”
Donne une métrique sur le pourcentage du
système testé : c’est la couverture des
tests.
Il va vérifier que les fonctionnalités sont au
moins exécutés une fois lors des tests.

15. Couverture12
15
Lance les tests
Vérifie que toutes les
fonctionnalités sont
testées et donne le
pourcentage de
couverture
Terminé!

16. Couverture12
16
100% :)

17. Couverture12
17
50% :(
?

18. Couverture12
18
100%
:)

19. Pourquoi ?12
Principalement pour savoir si un système est assez testé.
Une couverture élevée n’est pas un gage de qualité. Il nous faut une autre
métrique pour pouvoir juger si un système est correctement testé.
Il ne vérifie pas non plus que les tests sont OK ou NOK. Ce n’est pas son
job.
C’est le prochain robot qui va nous permettre de savoir ça.

20. Comment ?12

21. Comment ?12

22. Tests de mutation
13
2
2

23. Tests de mutations
23
13
Reprenons le robot du début mais, par
paresse, on le construit sans la
validation. Le test est incorrect / buggé
et ne teste rien.
- Le robot appuie sur le bouton
- Il vérifie que le contenu dans la tasse
est bien du café

24. Tests de mutations13
24
Appuie sur le
bouton
Produit du café
Ne vérifie RIEN

25. Tests de mutations
2
5
Appuie sur le
bouton
Produit du thé
Ne vérifie RIEN
13

26. Tests de mutations13
26
100% :)
La couverture n’aide pas
...

27. Réponse au problème
27
Nous devons … tester les tests pour
s’assurer qu’ils servent à quelque chose.
C’est le boulot des tests de mutation !
13

28. Tests de mutations
28
13
Lance et analyse les
tests
Générer un système
qui a subit une
mutation = qui produit
quelque chose que le
système ne produit
jamais - ex: jus
d’orange
Génère et lance le système
“muté”
Résultat des tests
Vérification que les tests ont échoués et
donne un pourcentage

29. Tests de mutations
29
13
On teste donc les tests pour valider que la couverture est correcte.
Il permet de détecter si des tests inutiles ont été réalisés pour augmenter la
couverture.
En analysant les tests une première fois - le mutation testing peut générer
des valeurs que le système ne produirait jamais - et donc tester que les
tests échouent - à raison car le système ne fonctionne pas
normalement.

30. Tests de mutations - Comment ?
30
13

31. Complexité cyclomatique
14
3
1

32. Complexité cyclomatique14
3
2
Permet de définir le nombre de tests /
cycles nécessaires pour couvrir
l’ensemble de fonctionnalités d’une
unité.
Imaginons qu’une seule fonction gère
les boutons de notre machine à café

33. Complexité cyclomatique14
33
Système testé: Contrôles de la machine à café
Une seule fonctionnalité faireCafe() qui produit toujours du café
1 test nécessaire

34. Complexité cyclomatique14
34
Deux fonctionnalités
si bouton bleu = faireCafe()
si bouton orange = faireCafeAuLait()
2 tests nécessaires

35. Complexité cyclomatique - Pourquoi ?14
35
Permet de valider qu’un système ne cherche pas à faire trop de choses.
Plus un système veut gérer des choses - plus il est dangereux car
potentiellement lourd à faire évoluer ou à maintenir.
Imaginez un système qui gère toutes les fonctions de notre machine à
café, ce serait un problème d’architecture du système.
On essaie de suivre le Principe de responsabilité unique. Chaque système
doit avoir une responsabilité unique et distincte.

36. Comment ?
36
14

37. Complexité
37
14
Elle est souvent calculé grâce à une moyenne. Certaines fonctions doivent
fonctionner différemment en fonction des paramètres donnés en entrée.
On prends souvent total / nombre de fonctions ou fichier (car un fichier
contient au moins une fonction)
Par exemple: 619 / 500 (fichiers) = 1.238

38. Autre métriques
3
8
15

39. Autres métriques
39
15
D’autres métriques existent
- % de duplication parce que deux boutons qui font la même chose ça ne
sert pas à grand chose
- Code “puant” mauvaise pratiques par rapport à un langage (souvent un
problème de syntaxe)
- Complexité cognitive est-ce que mon code est lisible simplement ?

40. Conclusion et étude de cas
4
0
16

41. Conclusion
41
16
Ces tests et métriques servent à valider la qualité d’un système.
“Un système devrait faire une seule chose et devrait bien le faire .
On s’assure que les fonctionnalités sont testées et correctement
testées
pour faciliter l’évolution et la maintenabilité du système en question.”

42. Etude de cas - Fédération Française de Tennis
- 90% de couverture du code dans les systèmes web et domain
- 10% de code mort (code inutilisé)
- Complexité cyclomatique de 3
- 5% de tests non résistants à la mutation
42
16
sur tout le code - nous sommes ~92% sur les systèmes web et domain
Pas de métrique - mais les outils de développement signalent automatiquement le code
mort et pas de warnings à ce sujet sur le projet
17% sur tout le code - nous sommes à ~ 10% sur les
systèmes web / domain
~ 1.24 sur tout le projet

43. APPSTUD
Questions ?
43