bbd dans le flow nov.2012
DESCRIPTION
Résumé : Au bout de 3 ans de pratique intensive du BDD avec Specflow en C#, je vous propose de passer en revue les avantages et les écueils de cette pratique, mais également partager "trucs et astuces" et surtout les questionnements qui restent en suspend. Bénéfices pour les participants : Apprendre et progresser sur le BDD et l'écriture de logiciel pilotée par les tests comportementalistes. Guillaume, Saint Etienne : Développeur depuis mon premier micro: un ZX81, j’ai endossé également différents rôles, principalement chez des éditeurs logiciels: chef de projet, architecte logiciel, scrum master , et encore maintenant « Senior Software Programmer ».TRANSCRIPT
dans le flux du BDD
Guillaume Saint EtienneGuillaume Saint Etienne@guillaume_agile@guillaume_agileVarian Medical SystemsVarian Medical Systems
ATTENTION
MISE AU POINT
TDD/BDD is a
design activityKerry Buckley
le test manuel est …
http://blog.objectmentor.com/articles/2007/10/17/tdd-with-acceptance-tests-and-unit-tests
mais il faut apprendre
idée: prenez un coach ;)
goOgle est mon ennemi
• Le TOP 50 des résultats pour « BDD » (en français)– Exemples simplistes et enfantins– Pas représentatifs d’un vrai projet logiciel– Pas de vrai retour d’expérience– Articles sur BDD = ATDD (Acceptance testing /
test d’IHM)
Exception!
• Il faut rendre à César ce qui est à Pierre Irrmann• http://www.arolla.fr/blog/2012/09/bdd-et-
specflow-pour-des-tests-plus-lisibles/• « Gherkin pour écrire des tests en langage
naturel ».• « Lorsqu’on développe en BDD, les tests sont
écrits pour tester des fonctionnalités et des exemples précis de comportements. »
Parcours empiriqueParcours empirique
Ce qu’on voit en 1er
• GHERKIN / CUCUMBER–Given–When–Then
Don’t misuse it!
Ce que m’apporte la forme BDD
T.U. classique
• ARRANGE• ACT• ASSERT
T.U. Behavioriste
• GIVEN• WHEN • THEN
•Given•When•Then
•Given•When•Then
Organisation du BDD
Librairies
Features
Scenarios
Steps
Ce qui est trompeur
La puce à l’oreille
• La section « Feature » dans Gherkin– In order to– As a– I want to
…ne sert à rien!!!!
Elle n’est pas compilée et donc pas « exécutée »
Auteur: Brian Marick
Tester c’est comprendre
• du latin « comprehensio »1, de « cum », avec, et « prehendere », prendre: action de saisir ensemble ou de prendre avec soi
DEBUG BDD
BDD = Test Comportementaliste
Idées reçues sur le BDD• You want to do acceptance testing rather than
unit testing.• You want to use it as a communication tool
with the stake holder.• You want to do large scale tests rather than
granular tests.• You want non-technical people to write the
tests.http://gojko.net/2012/06/18/bdd-busting-the-myths/ [Gojko Adzic]http://stackoverflow.com/questions/2238176/using-fitnesse-rather-than-nunit
You want to do acceptance testing rather than unit testing.
You want to do acceptance testing rather than unit testing.
You want to do acceptance testing rather than unit testing.•TDD is excellent
You want to do acceptance testing rather than unit testing.•TDD is the only way to be agile•BDD is no more than TDD
You want to do acceptance testing rather than unit testing.•TDD is the only way to be agile•BDD is no more than TDD•BDD is first doing « unit » testing
You want to do acceptance testing rather than unit testing.•TDD is the only way to be agile•BDD is no more than TDD•BDD is first doing « unit » testing•A «non-unit » test is a scam!
– Test only one thing at a time
You want to use it as a communication tool with the stake holder.
You want to use it as a communication tool with the stake holder.First, use it as a communication with yourself
You want to use it as a communication tool with the stake holder.First, use it as a communication with yourself…then your team
You want to use it as a communication tool with the stake holder.First, use it as a communication with yourself…then your team…then (maybe) the stakeholder or the users.
You want to do large scale tests rather than granular tests.
You want to do large scale tests rather than granular tests.
You want to do large scale tests rather than granular tests.
http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1
Why integrated tests are a scam!Why integrated tests are a scam!
• I use the term integrated test to mean any test whose result (pass or fail) depends on the correctness of the implementation of more than one piece of non-trivial behavior.– J. B. Rainsberger
You want non-technical people to write the tests.
You want non-technical people to write the tests.
You want non-technical people to write the tests.
•I wish I could …
You want non-technical people to write the tests.
•I wish I could …•Be pragmatic!
You want non-technical people to write the tests.
•I wish I could …•Be pragmatic!•Maybe in the future …
Bref, j’ai fait du BDD
• Je passe à une description textuelle• Exemple!
Bref, j’ai fait du BDD
Given I initialize the readerAnd jouvre le dossier patient '1'When je veux lire 'nom' Then I dont have errorAnd jobtient une valeur 'Nom 1'
Et si? Je n’avais pas fait du BDD
DRY
• Mes tests aussi !• Refactoring• Les Steps Given/When/Then sont une façon
de « DRY »• Puissance (et pièges) des expressions
régulières.• Exemple…
Given I initialize the readerAnd jouvre le dossier patient '1'When je veux lire 'nom' Then I dont have errorAnd jobtient une valeur 'Nom 1‘
Given I initialize the reader And jouvre le dossier patient '1' When je veux lire 'nais' Then I dont have error And jobtient une valeur '2/1/1973'
L’envers du décors: les Steps
Given I initialize the readerAnd jouvre le dossier patient '1'When je veux lire 'nom' Then I dont have errorAnd jobtient une valeur 'Nom 1‘
Given I initialize the reader And jouvre le dossier patient '1' When je veux lire 'nais' Then I dont have error And jobtient une valeur '2/1/1973'
Given I initialize the reader And jouvre le dossier patient 'F2' And the log system is initialized with the LogWatch configuration When I read ‘droits' as a Numeric Then I have an error And the previous log messages contains: The field 'droits' couldn't be read as a Decimal
Exemple de refactoring
• On fini par gagner énormément de temps
• Fini le copier/coller… dans le code !
• Donc fini les erreurs…. sur le code (technique)
des tests!
• Exemple!
1 Feature
1 Feature
Les Tables Specflow
Looks like Fitnesse (a bit)
Refactoring en BDD
• Nécessité de créer des Steps efficaces• Ils sont exécutables, donc il y a du code
derrière.• Même qualité du code des steps que du reste
du code.• Ré-utilisables
– Then I dont have error
Les outils incontournables
– Dummies– Fake– Mocks– Stub– Espions / Spies– Inversion de contrôle / Injection de dépendance– Helpers
– … comme dans le TDD après tout!
Fake / Substituts
• De faux objets ayant un comportement similaire à l’objet réel, mais d’une façon simplifiée.
• Il n’agit pas comme un point de contrôle, mais permet d’accélérer l’exécution des tests.
• Par exemple en remplaçant l’accès à la base de données par des données dans un fichier ou en mémoire.
Fake• « Doublure » qui fait comme l’original
ORM DB4
Test
Db 4 ObjectFile
Mocks• Une « leurre » mais pas besoin d’écrire son
code « interne »• Juste décrire ce que l’on attend de lui
Mock• Le Mock se contente de bien se « comporter ».• Simulation (Setup)• Vérification du comportement attendu
(optionnelle).
outillage contratS.U.T.
comportement attendu
Stubs
• Similaires aux MOCKs• La différence principale vient du fait qu’avec le
Stub on vérifie l’état de l’objet alors qu’avec le Mock on en vérifie le comportement (les interactions).
• http://bruno-orsier.developpez.com/mocks-arent-stubs
Refactoring steps with helpers
• Une syntaxe pour accéder aux objets (C# 3.5)• Sans:
– When je lis le champs ‘City’ dans la 1e adresse du patient en cours And je lis le champs ‘Type’ dans la 1e adresse du patient en coursAnd je lis le champs ‘Type’ dans la 2e adresse du patient en coursAnd je lis le champs ‘Type’ dans la 3e adresse du patient en cours
• Avec:
Au final, qu’est ce que je teste?
• SUT / SCT : System Under Test / Système en Cours de Test
• L’Isolation des tests est indispensable (1 problème à la fois)
• Impossible de se passer des doublures.• Un exemple avec les Spies / Espions
Single Responsibility
Chainage des vérifications
• Pas besoin de tests automatisé intégrés.• Si tous les mécanismes vu précédemment
sont en place.• Néanmoins, comment en être sûr?
S.O.L.I.D.• Single responsibility principle
– the notion that an object should have only a single responsibility.
• Liskov substitution principle– the notion that “objects in a program should be
replaceable with instances of their subtypes without altering the correctness of that program”
• Interface segregation principle– the notion that “many client specific interfaces are
better than one general purpose interface
Si mon code est SOLID• Alors mes tests doivent l’être aussi
Les CONTRATS sont la clé
Vérification automatique
• => Outil de couverture de code.
• Néanmoins difficile d’avoir 100% (erreurs de
l’outil, code inatteignable)
• Donne une très bonne mesure de
l’amélioration de la couverture par les tests.
Autres vérifications à faire
• Complétude des tests• Les « fakes » doivent être testés à leur tour.• Parcours et vérifications auto. des interfaces:
– Si une doublure (spy/mock/stub) se fait passer pour une interface, et qu’on n’en trouve pas une implémentation qui ne soit pas couverte à 100% par d’autres tests (eux même en parfaite isolation), alors c’est un échec!
– À inventer!
Patterns: HUMBLE DIALOG, VISITOR
Tests devenus inutiles: UI
Tester à partir des UI?
Test the User Interface?• « Tests »
Exploratoires (manuels)– Si Erreurs
détectées: • 5% pb de config• 10% coquilles• 10% I/O - Sys• 75 % manque de
tests
L’HEURE DU BILAN
Dans le flux
Avant le BDD
Après (dans le flux)
Ecriture du test: 5 à 30min
Steps• Écriture: 5mn à 2h
Steps• Refactoring: 1/2 à 1 journée
BILAN
La question n'est pas: combien je gagne à faire des tests? Mais,combien je perd à chaque bug en prod. #atmrs2012
Summary01/06/2010 10/10/2012 - 1:39:45 PM
8 Applications livrées (+ 6 logiciels d’installation)Tests running (2x day): 1564, Failures: 0, Inconclusive: 0, Time: 2158 seconds
STEPS:167 Given, 183 When, 209 Then 44 R. --- , 77 R.---- , 73 R. ( 26% , 42% , 35%)
Efficacité moyenne 1 groupe de steps couvre 10 scénarios
« Manual » LOC of tests/specs: 12557 / 176595 ( 14%) source monitor
Source Files: 460 (comptage par OpenCover)
Coverage: 74.5% (15% UI 10% autre non couvert)
Covered lines: 9818 (comptage par OpenCover)
Coverable lines: 13161 (comptage par OpenCover)
Total SLOC Executed in tests: 48248 (comptage par OpenCover)
BÉNÉFICES OBSERVABLES
Charge de travail effective
• Nombre de bugs déclarés en exploration et après livraison:– 1ere année: 51– 2ème année: 27
• Nombre de WorkItems (User Needs, Design Quality)– 1ere année: 98– 2ème année: 100
Les tests peuvent être lus
• Ce n’est (presque) plus du code, c’est du texte!!
• On change de perspective (passer de l’impératif au descriptif).
• Je peux échanger avec mon équipe plus vite.• Quelqu’un de non technique pourrait-il les
comprendre? Les écrire ?
Mais on est encore très loin du langage naturel
• P.O et skateholders ne comprennent (pour l’instant) pas tout.
GAP
GAP
https://docs.google.com/viewer?url=http%3A%2F%2Fwww.scrumalliance.org%2Fsystem%2Fslides%2F118%2Foriginal%2FChristianHossa_SpecificationByExampleWithGherkin.pdf%3F1349824954
Qu'est ce que mon test raconte?
• Un scénario.• Même s’il revêt une réalité technique, le
comportement devrait pouvoir être compris et approuvé par quelqu’un de logique.
• Il ne doit cibler qu’une chose à la fois(isolation).
MIEUX RACONTER
• Etre rigoureux à l’écriture des Steps• Se conformer au Domaine (Domain Language)• Faire du Domain Driven Design précisément
• Tests qui resteront techniques et ceux qui seront plus proches du fonctionnel
• Masquer la technique tout en permettant une bonne réutilisation des steps (!)
Est ce suffisant pour faire une documentation?
Souvent!
• Si c’est bien raconté, oui pour spécifications.• Doc Technique = OUI ! SI! YES ! JA ! DA!• Pèsera autant qu’un lourd cahier de tests.• On a gagné des semaines (voir des mois)
hommes de travail de rédaction et de vérifications.
• Export automatique des fichiers Specflow -> Html, Word, Pdf.
Décrire
Descriptif n’est pas Impératif
C’est s’intéresser à l’essentiel
• On ne voit bien qu'avec le test. L'essentiel est invisible pour les yeux.
Antoine de Saint-Test
Tests that saves faith
Références
Pardon
• à Antoine de Saint-Exupéry
à relire (souvent)
BDD dans le flux2e partie
Du Mythe à la réalité
TOUT POUR FACILITER LES TESTS
Changement de vision
Penser le comportement
Les vertus de l’abstraction
Concevoir un comportement
• C’est penser en terme FONCTIONNELS
Design émergeant
Une affaire de style
Changement de style
• the system can’t neatly be tested with automated test suites because part of the logic is dependent on often-changing visual details
• http://alistair.cockburn.us/Hexagonal+architecture
La gravité
Dépendances fatales
Modèle sans gravité
Domain Driven Design
• C’est le meilleur moyen d’être proche du domaine métier de votre client
• Exemple (description BDD et objet métier)
Le Domaine comme modèle agnostique entre les composants
Ce que le Domaine n’est pas!
• Gestion des états => • Stateless =>
Ce que le domaine n’est pas!
Polyglot Data
• Le meilleur moyen d’être Data Storage Agnostic
• Ce n’est plus le DBA qui commande• SQL / NoSQL ?• La persistance est un plus, voila tout.• Exemple: le FakeStorer dans les tests
Incidences sur le code1. Ecrire des Interfaces qui décrivent (abstraire)
ce que les tests vont spécifier dans des scénarios mettant en évidence la valeur ajoutée du comportement choisi.
2. Ecrire l’implémentation ensuite.
3. L’intégration continue vérifie tout automatiquement => non régression.
Responsabiliser le code
• Isolation = Une seule responsabilitéTester c’est apprivoiser.
• « Tu deviens responsable pour toujours de ce que tu as testé »
Antoine de Saint-Test
Toujours plus fluide
• Le style change• On devient plus « fluent »• Le code se lit (presque) comme une phrase en
langage naturel• On se rapproche de la programmation
fonctionnelle (sans changer de langage)• Fluent API + lambda expressions = le chainon
manquant?
En Pratique
• des DOJOS pour montrer que bien tester en 1er, et tester par le comportement induit un changement de vision dans le design du logiciel
• Une mise en œuvre des tests et du code par la simplicité, la rigueur et l’efficacité
• des exemples bientôt sur mon site http://www.dotnetguru2.org/gse/
LES TESTS D’INTEGRATION SONT ILS UTILES?
Comment on a tuer l’intégration
• Créez (ou utilisez) un mécanisme d’intégration automatique
• Testez le!• => plus besoin de tester en intégration• Ajoutez tous les tests qu’il faut pour renforcer
l’intégrité du tout.• Est-ce une bonne chose?
Du mythe…
A la réalité
UN ŒIL SUR LES ESPIONS
En pratique
S.U.TVérification de comportement en parfaite isolation
SONT-ILS BIEN TESTES?
Les pièges à éviter
• Dire « comment » au lieu de « quoi »• Ne pas laisser transparaitre le « software
design »• Le « software design » devrait se fondre dans
les spécifications et devenir naturel• Ne pas se laisser enfermer dans les détails • Ne pas tout tester en même temps (bis
répetita)
Pièges (Suite)• Garder les tests parlants… (pour qui?)• Ne pas sur-spécifier (YAGNI sur les tests)• La partie setup/Given devrait rester simple• Utiliser un « ubiquitous languange »• Ne retardez pas l’usage des doublures,
injection de dépendance et autres assistants• Ne pas sous-estimez votre code « assistant »
(testez les aussi bien)
• Introduire une part de travail manuel
(suite)
• Se baser sur des données pré-existantes(!!)• Ne pas être certain que chaque test soit
idempotent.• Perdre du sens par soucis de concision
(masquer la réaliter au lieu de la simplifier)
• L’endettement (on fini toujours par payer, et les taux augmentent avec le temps)
Trucs• Commencer petit• Progresser à son rythme• Refactorer régulièrement• Le temps est votre allié
DRY! KISS! YAGNI! SOLID!
Tests that saves faith