iut agile lyon 20 nov. 2013 - bdd
TRANSCRIPT
Behaviour-Driven Development
IUT Agile Lyon - 20 nov. 2013
@agnes_crepet
@AlfredAlmendra
Java/JEE Architecte & Java Champion Laboratoires Boiron Ninja Squad Java User Groups Leader:
Duchess FranceLyonJUG
Co-fondatrice de la conférence
Agnès CREPET
Acronymes
Spécification par l’exemple
Spécification exécutable
BDD : origine(s)
TDDTest Driven Development
BDD : origine(s)
USDDUser Story Driven Development
BDD vs TDD
BDD parle un langage du métier, écrit en texte
TDD parle un langage technique, écrit en code
Complémentaires et non en conflit !
BDD vs ATDD
ATDD est un paradigme générique d’automatisation des tests d’acceptation
BDD permet d’automatiser les tests, en mettant l’accent sur la communication
BDD : origine(s)
DDDDomain Driven Design
BDD : origine(s)
Dan North
Tester c’est décrire le
comportement
Un langageuniversel c’est la
clef
Automatiser les testsd’acceptation
Toute exigencedeviendra un
comportement
BDD : pourquoi ? quels bénéfices ?
Visibilité sur l’avancement
Critère DONE
Démo réussie
Validation du but de l’itération
Acceptation du produit
Couverture des tests fonctionnels
Non régression
Etude d’impact
BDD : quoi ?
Point de vue des utilisateurs finaux
DEMO :
CRAFTSMAN
PLAN
BDD : quoi ?
Boîte noire
Aux frontières du système
On ne décrit pas le comment
BDD : quoi ?
Décrire le comportementet non pas le fonctionnement
BDD : quoi ?
Langage commun
Ubiquitous languagede DDD
BDD : clés de la réussite
Découpagepriorisationcycle itératif et incrémental
Point de vuede l’utilisateurCollaboration
Intégration continue
Test First !
Exemple avec should
→
Exemple avec GherkinGiven the distance max is 50 km per day And I meet M John on “20/11/13” 10 km away And I meet Ms Shelp on “20/11/13” 12 km awayWhen I try to meet M Bob on “20/11/13” 8 km away Then I still have only 2 appointements on “20/11/13”
Structure de test → 1 méthode par step
BDD : quand ?Découper
Estimer
S’engager
Coder Démontrer
UtiliserPréciser
BDD From Scratch
Code
Spec
Test
Comment démarrer de zéro ?
RAD : Rapid Application Development
Exploration & émergence ⇒ refactoring
Make
Fake
Fake Make
Make
1 2Make
IHM
BdD
Métier
Double loop TDD
Acceptance Test loop Unit Test loops
Refactor
Fail
Pass
Maintenance BDD
Versionning des spécifications
?Refactoring des spécifications
Poser les bonnes questions
Etude d’impact
Expérimentation d’alternatives
BDD sur du legacy
Legacy = non testé (automatiquement !)
On ajoute du BDD sur une application existante→ Non intrusif
Une nouvelle partie fonctionnelle : ok (serein)Une adaptation : impact ? effets de bords ?Une refonte : couverture en tests fonctionnels ?
Retours terrain
Pas à pas : User Story, scénario d’acceptationTest First : discipline, paradigme
Test ? scénario, méthode, exécution, step
Gherkin : pas pour le métier, dur pour l’analysteStructuration d’un scénario en français : ok
Ne remplace pas : tests “après”, recette intégrée
As a conclusion...
Ressources
Un exemple BDD avec cucumber-JVM:https://github.com/acrepet/craftsmanplan
Le blog de Dan North:http://dannorth.net
