La présentation traite de la mise en place de tests automatisés dans un environnement non agile, en se concentrant sur le développement agile et les spécifications par le biais de tests d'acceptation. Elle met en avant l'importance d'un langage commun et de la collaboration entre les développeurs et les métiers pour améliorer la qualité du code et faciliter la gestion des spécifications. Des exemples concrets d'automatisation avec JBehave et des retours d'expérience sur le refactoring de code legacy sont également partagés.

2. Yannick Grenzinger & Clément Rochas
Faites (re)vivre vos
spécifications

3. MERCI À NOS SPONSORS

4. Cette présentation est...
• Un REX!
• Une démo de mise en place de tests
automatisés!
• Un exemple de développement agile
en dans un milieu qui ne l’est pas…

5. “Quand le client m’affirme qu’il ne
retrouve pas les fonctionnalités
precisées dans sa spec”

6. “Quand je viens de finir les specs et
que je n’y ai rien compris”

7. Too
long!
didn’t
read

9. Le contexte
• Opérateur téléphonique!
• Pas agile dans le process!
• Culture du héro

10. Le concept de l’appli

12. Warning: L’image suivante peut
heurter la sensibilité des
plus agile d’entre nous.

13. LOT 1

15. Quand la loi ne peut plus rien
pour vous, il vous reste un
recours...
The A(gile)TEAM

16. Racontez moi tout
depuis le début...

17. Décrire les comportements langage commun
(Given)(Etant donné) un contexte
(When)(Lorsque) l'utilisateur effectue certaines actions
(Then)(Alors) on doit pouvoir constater telles conséquences

18. Rétro story map

19. Les user stories composés
En tant d'utilisateur Je veux quelque chose de très complexe !
afin de faire l’action A
En tant que composant X !
Je veux implémenter
l’opération Y !
afin de faire l’action C !
et contribuer à A
En tant que composant Z !
Je veux implémenter
l’opération X afin de faire
l’action B !
et contribuer à A
Utilisateur
Composant

20. Spécifier par l’exemple
Exemples
BDD
Tests
d’acceptation
Spécifications liées aux
domaines métiers
Décrivent Vérifient
se transforment
Le tout
automatisé

21. Et maintenant comment on automatise?

22. JBehave: Ecrire notre 1er test BDD en 5 min
Un projet avec une classe Panier, nous allons utiliser JBehave
mvn archetype:generate -> 686 -> fr.xebia -> demo-scrumday
Scenario: Calculer le prix total du panier après avoir appliqué une taxe
Given un panier avec un prix total de <prixTotal> euros
And une taxe de <taxe>%
When on calcule le prix total avec la taxe
Then le prix total avec la taxe est de <prixAttendu> euros
Examples:
|prixTotal|taxe|prixAttendu|
| 100 | 0.2 | 120 |

23. Histoire d’un refactoring
Comment le BDD nous a permis de comprendre, de s’approprier et de
refactorer le legacy.!
!
Story:
En tant que catalogue, Je veux valider l'intégrité des groupes d’options
!
Un peu de contexte!
une offre contient X groupes
chaque groupe contient X options
On veut vérifier que les options des groupes sont cohérentes

24. Notre story sous format BDD
Scenario: tester l’intégrité des groupes d’options d’un panier client
Given un groupe Débit Internet d'une offre Mobile
Given on <action1> une option Internet Illimité
Given on <action2> une option 100mo chaque mois
When le catalogue vérifie l'intégrité des groupes
Then le statut panier est <statutPanier>
Examples:
| action1 | action2 | statutPanier |
| SOUSCRIT | SOUSCRIT | KO |
| SOUSCRIT | RESILIE | OK |

25. traiter l’étape
Classe
Méthode
Offre
N groupes
N options
récupère les données de l’étape précédente
trier les options sélectionnées suivant le groupe associé
Parcourir les options et vérifier qu’on ne dépasse pas le
maximum
Parcourir les groupes et vérifier que chacun a le nombre
minimum d’options
compter le nombre d’options proposables dans un groupe
Récupérer le groupe associé à l’option
Step: Vérifier groupe

26. Step: Vérifier groupe
compter le nombre d’options proposables dans
un groupe
Classe
Méthode
Offre
N groupes
N options
récupère les données de l’étape précédente
Pour chaque groupe de l’offre, vérifier si le
nombre d’options est correct
Calculer le nombre d’options sélectionnés dans
un groupe

27. ● Jbehave (ou JUnit ou EasyB)
● Selenium/Webdriver
● Rapports

28. Et nous qu’est ce qu’on laisse aux prochains
développeurs ?
• Pas de spécifications mais une image à
l’instant T du code;!
• Une cartographie fonctionnelle de l’appli;!
• Des comportements automatisés donc des
tests de non régression;

29. La story map comme gilet par balle

30. Take away
➢ Adopter un langage commun autour du métier!
➢ Faire confiance au dev pour le code :-)!
➢ Augmenter la qualité du code avec des tests de
non régression … métier !!
➢ Possibilité de reprendre du code legacy en
repartant du métier!
➢ Être transparent, suivre l’avancement en terme
de fonctionnalité

31. Merci!