Talk Behavior Driven Development donné à la conférence AgileTour 2011 à Strasbourg.

1. Behavior Driven
Development avec
Cédric Vidal, Dir. Technique., ProxiAD IDF
14 Novembre 2011
Twitter: @cedricvidal
Ne lisez pas la spec…
…exécutez la !

2. Intervenant
• Cédric Vidal
– Architecte JavaEE et MDE
– Directeur Technique de ProxiAD IDF

3. Holdin
g 2003
ProxiAD
Nord Lille
1997
Syntonia
Paris 2004
ProxiAD
Ile de
France
Paris 2004
ProxiAD
Bulgarie
Sofia 2005
ProxiAD
Ouest
Nantes
2005
ProxiAD
Normandie
Rouen
2005
ProxiAD
Est
Strasbourg
2010
ProxiAD
Rhône-
Alpes Lyon
2010
8 filiales
390
collaborateurs
C’est …

4. Notre métier
• Conception
• Réalisation
• Conseil
• Expertise
• Objet
• Décisionnel
• Centre de service
• Industrialisation

5. Le menu du jour
1. La problématique
2. Objectifs
3. Le BDD
1. Gains & inconvénients
2. TDD
4. Jbehave
1. Basiques
2. Demo 1
3. Customisation
5. Cas 1: RDA
6. Cas 2: Flux boursiers
1. Demo 2

6. http://gojko.net/2008/08/29/how-many-points-are-there-in-a-five-point-star/
à question simple…

7. http://gojko.net/2008/08/29/how-many-points-are-there-in-a-five-point-star/
…réponse simple ?

8. Problématique
• Pour la MOA / les fonctionnels
– Ce qui est développé par la MOE est-il conforme
aux attentes ?
– Comment spécifier de la manière la plus efficace
• Pour la MOE / les développeurs
– Ce qui est développé est-il conforme aux attentes
de la MOA ?
– Comment savoir quand s’arrêter ?

9. Objectifs
• Pour la MOA / les fonctionnels
– Obtenir le produit souhaité
– Etre compris par les développeurs
– Mieux définir le produit souhaité
• Pour la MOE / les développeurs
– Développer le produit le plus simple répondant
aux besoins de la MOA
– Perdre le moins de temps possible

10. Le BDD propose:
• aux fonctionnels d’écrire en français des
stories …
• … qui seront ensuite rendues
exécutables par les développeurs
• … et qui serviront de fil d’ariane pour les
développements

11. Gains
• L’écriture de la story permet aux fonctionnels de
mettre à plat leur besoin
• Guide les développements par les spécifications
exécutables
• Critères d’acceptance fonctionnelle
• Non régression fonctionnelle
• Sécurise les développements
• Contractualisation de la relation MOA/MOE

12. Ce n’est pas
• Attention, les stories ne sont pas:
– Un critère d’acceptance technique
– Ce n’est pas parce que les stories passent que
techniquement, tous les cas de figures sont gérés
– Les stories ne testent pas tous les cas de figure
– => à compléter par des tests technique: unitaires,
d’intégration

13. Compléter par du TDD
• Vision technique
• Types de tests
– Tests unitaires
– Tests d’acceptance
– Test d’intégration
• Vocabulaire
– Etat initial / Action / Assertion
• Gains
– Non régression technique
– Critère d’acceptance technique
Test d’intégration
technique
Test
Unitaire

14. Difficultés 1/2
• Nécessite de l’attention régulière
• De l’implication
• Qui écrit les stories ?
• Les développeurs ou les fonctionnels
• « c’est trop de travail »
• => personnes non impliquées
• Difficile d’obtenir l’adhésion
• des fonctionnels
• des développeurs

15. Difficultés 2/2
• Parfois perçu par la MOA comme un engagement
contractuel
• Parfois perçu par les développeurs comme un effort
trop important
• Première tâche qui passe à la trappe en cas de
pression sur le projet

16. FRAMEWORK DE BDD

17. Une story
17
• Description des scénarios en français libre
• Approche basique de matching des phrases
– Pas d’analyse grammaticale
• Chaque phrase exécute simplement du code bindé

18. 18
Instrumentation de la story: Given

19. 19
Instrumentation de la story: When

20. 20
Instrumentation de la story: Then

21. 21
Phrases types réutilisables
• Given
– la fenêtre "" est active
– l'utilisateur a le droit de ""
– l'utilisateur courant est ""
• When
– l'utilisateur clique sur le bouton ""
– l'utilisateur choisit la valeur "" dans la liste ""
– l'utilisateur saisit la valeur "" dans le champ ""
• Then
– la fenêtre "" est active
– le titre de la fenêtre active est ""
– la fenêtre est modale
– la liste "" est remplie par ""
– le champ "" contient la valeur ""

22. 22
Etats possibles des steps
• PASSED: instrumenté, exécuté, succès
• FAILED: instrumenté, exécuté, échec
• PENDING: non instrumenté
• NOT PERFORMED: instrumenté, pas exécuté
car bloqué par un step FAILED précédent

23. 23
Exemple d’exécution
Running story fr/cosi/stories/CS_US_001_CreerOperation.story
(fr/cosi/stories/CS_US_001_CreerOperation.story)
Scenario: Création d'une opération d'infrastructure
Given la fenêtre "Organiser le projet" est active
Given le projet "2820120110001" est selectionné
When l'utilisateur clique sur le bouton "Créer une opération"
Then la fenêtre "Créer une opération" est active
Then le champ "Projet" contient la valeur "2820120110001 - Transfert du régiment 1"
When l'utilisateur choisit la valeur "Eid Versailles" dans la liste "Organisme"
When l'utilisateur saisit la valeur "Réfection" dans le champ "Libellé"
When l'utilisateur clique sur le bouton "Enregistrer"
Then le titre de la fenêtre active est "Modifier l'opération" (FAILED)
(org.junit.ComparisonFailure: expected:<[Modifier l'opér]ation>
but was:<[Demande de confirm]ation>)
Then le champ "Opération" contient la valeur "0003 - Réfection de l'infirmerie«
(NOT PERFORMED)
Then l'onglet "Qui où" est accessible (PENDING)

24. DEMO 1

25. Plusieurs lancements
possibles
• Depuis un lanceur JUnit, une story par lanceur
– Plus orienté développeur
• Depuis un lanceur JUnit, toutes les stories
d’une arborescence
– Plus orienté fonctionnels
• Depuis Maven
• …

26. Intégrations possibles
• Intégration Guice
• Intégration Spring
• Intégration Mockito
• Intégration Mycilla

27. Customisations possibles
• Langue
• Résolution des stories & examples
• Format des examples: possibilité d’ajouter ses
propres formats de fichiers mais pas évident

28. Résolution des stories &
examples
• Inclus
– Relativement à un chemin
– Relativement à une URL
• Locale, FTP, HTTP, WebDAV, …
– De manière absolue dans le classpath
• Nécessite une customisation:
– relativement au lanceur JUnit

29. Relativement au test

30. Examples CSV
• Pas inclus de base
• Nécessite une customisation

31. IoC & BDD ?
• Permet un accès à tous les
composants du système par
injection dans les steps
• Permet de piloter tous les
composants
• Permet de customiser
simplement n’importe quel
composant du système
• Assemblage des couches
spécifique à l’environnement
souhaité pour les tests
SUT
Tes
t

32. Exemple
• Base de donnée mémoire: H2
– Compatible Oracle, Postgres, …
• API FileSystem virtualisée
• Systèmes externes mockés:
– Serveur FTP, …
• ….

33. RDA SWING / GUICE
Premier exemple

34. Contexte
• RDA Swing
• IoC avec Guice

35. 35
Comment faire
le lien entre les
noms métier et
le code ?
?

36. 36
Pas par le titre
• Plusieurs instances différentes d’une même
vue peuvent avoir des titres différents

37. 37
En marquant le code
• Avec des annotations Java5

38. 38
API Graal: GraalUtil

39. 39
GraalUtil dans les steps

40. OUTILLAGE

41. 41
Emplacement des stories
story
Lanceur JUnit
CS_US_XXX_<NomUserStory>.story
CS_US_XXX_<NomUserStory>_Story.java

42. 42
Emplacement des steps

43. 43
Lancement d’une story

44. 44
Lanceur de stories JUnit
Comportement commun à toutes les stories
Exécutable avec JUnit
Liste des modules Guice
chargés pour la story

45. 45
Editeur de story
(Merci Patricia)

46. TRAITEMENT DE FLUX BOURSIERS
Deuxième example

47. Contexte
• Métier
– Serveur de traitement de flux boursier
• Middlewares:
– Mémoire distribuée HA: Hazelcast
– Stockage longue durée: Postgres
– Routage et connecteurs: Camel
– IoC: Guice

48. Vue d’ensemble
Serveur
Flux boursier Reports
Console de monitoring
& administration
Euronext
Paris
New york
Journaux
en ligne
Journaux
papier

49. Besoin
• Pas de caractères observables extérieurs
permettant de vérifier le bon fonctionnement
du serveur
• Simuler des stories dans un contexte distribué
• Pilotage des nœuds du cluster
• Traitements internes très complexes
• TDD & BDD particulièrement intéressant
dans ce contexte

50. DEMO 2

51. ANNEXES

52. COMMENT FAIRE DU BDD AVEC
UNE IHM ?
Mocking des vues

53. Difficultés
• Pouvoir simuler les saisies utilisateur
• Pouvoir identifier les composants graphiques
par leur nom fonctionnel
• Pouvoir tolérer des changements de layout
• Pouvoir vérifier des assertions sur l’état de
l’IHM

54. Approches BDD IHM
• Approche robot: FEST, …
– Simulation au niveau interface réelle
• Approche pattern MVP
– Simulation au niveau présenteur

55. MVP
View
« JavaBean
»
Mocked
View
Swing View
Presenter Model
get/set
notify
notify
action
•Problèmes
•Manque de librairies de mock Swing
•Manque de composants graphiques compatibles
MVP

56. 56
Conf IoC Swing
Implémentation Swing
Interfaces des vues
SwingUiConfIoc

57. 57
Mocking des vues pour les stories
• Mocking avec Mockito
• Comportement JavaBean
Implémentation JavaBean mockée
Interfaces des vues
MockUiConfIoc

58. 58
mockBean
• Permet de donner un comportement JavaBean à une interface
Une interface défini
des getters/setters

59. 59
mockBean
• remplace • par

60. Questions ?