Your SlideShare is downloading. ×
0
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Bbd dans le flow nov.2012
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Bbd dans le flow nov.2012

351

Published on

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 …

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 ».

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
351
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. dans le flux du BDD Guillaume Saint Etienne @guillaume_agile Varian Medical Systems
  • 2. ATTENTION
  • 3. MISE AU POINT
  • 4. TDD/BDD is adesign activity Kerry Buckley
  • 5. le test manuel est …http://blog.objectmentor.com/articles/2007/10/17/tdd-with-acceptance-tests-and-unit-tests
  • 6. mais il faut apprendre idée: prenez un coach ;)
  • 7. 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)
  • 8. 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. »
  • 9. Parcours empirique
  • 10. Ce qu’on voit en 1er• GHERKIN / CUCUMBER –Given –When –Then
  • 11. Don’t misuse it!
  • 12. Ce que m’apporte la forme BDDT.U. classique T.U. Behavioriste• ARRANGE • GIVEN• ACT • WHEN• ASSERT • THEN
  • 13. Organisation du BDDLibrairies Features Scenarios Steps ••Given Given ••When When ••Then Then
  • 14. Ce qui est trompeur
  • 15. 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 » 
  • 16. Auteur: Brian Marick
  • 17. Tester c’est comprendre• du latin « comprehensio »1, de « cum », avec, et « prehendere », prendre: action de saisir ensemble ou de prendre avec soi
  • 18. DEBUG BDD
  • 19. BDD = Test Comportementaliste
  • 20. 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
  • 21. You want to do acceptance testing ratherthan unit testing.
  • 22. You want to do acceptance testing ratherthan unit testing.
  • 23. You want to do acceptance testing ratherthan unit testing.•TDD is excellent
  • 24. You want to do acceptance testing ratherthan unit testing.•TDD is the only way to be agile•BDD is no more than TDD
  • 25. You want to do acceptance testing ratherthan unit testing.•TDD is the only way to be agile•BDD is no more than TDD•BDD is first doing « unit » testing
  • 26. You want to do acceptance testing ratherthan 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
  • 27. You want to use it as a communication tool withthe stake holder.
  • 28. You want to use it as a communication tool withthe stake holder.First, use it as a communication with yourself
  • 29. You want to use it as a communication tool withthe stake holder.First, use it as a communication with yourself…then your team
  • 30. You want to use it as a communication tool withthe stake holder.First, use it as a communication with yourself…then your team…then (maybe) the stakeholder or the users.
  • 31. You want to do large scale tests rather thangranular tests.
  • 32. You want to do large scale tests rather thangranular tests.
  • 33. You want to do large scale tests rather thangranular tests.http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1
  • 34. 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
  • 35. You want non-technical people to write thetests.
  • 36. You want non-technical people to write thetests.
  • 37. You want non-technical people to write thetests.•I wish I could …
  • 38. You want non-technical people to write thetests.•I wish I could …•Be pragmatic!
  • 39. You want non-technical people to write thetests.•I wish I could …•Be pragmatic!•Maybe in the future …
  • 40. Bref, j’ai fait du BDD• Je passe à une description textuelle• Exemple!
  • 41. Bref, j’ai fait du BDDGiven I initialize the readerAnd jouvre le dossier patient 1When je veux lire nomThen I dont have errorAnd jobtient une valeur Nom 1
  • 42. Et si? Je n’avais pas fait du BDD
  • 43. 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…
  • 44. Given I initialize the readerAnd jouvre le dossier patient 1When je veux lire nomThen I dont have errorAnd jobtient une valeur Nom 1‘Given I initialize the readerAnd jouvre le dossier patient 1When je veux lire naisThen I dont have errorAnd jobtient une valeur 2/1/1973
  • 45. L’envers du décors: les Steps
  • 46. Given I initialize the readerAnd jouvre le dossier patient 1When je veux lire nomThen I dont have errorAnd jobtient une valeur Nom 1‘Given I initialize the readerAnd jouvre le dossier patient 1When je veux lire naisThen I dont have errorAnd jobtient une valeur 2/1/1973Given I initialize the readerAnd jouvre le dossier patient F2And the log system is initialized with the LogWatch configurationWhen I read ‘droits as a NumericThen I have an errorAnd the previous log messages contains: The field droits couldnt be read as a Decimal
  • 47. 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!
  • 48. 1 Feature
  • 49. 1 Feature
  • 50. Les Tables Specflow
  • 51. Looks like Fitnesse (a bit)
  • 52. 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
  • 53. 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!
  • 54. 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.
  • 55. Fake• « Doublure » qui fait comme l’original DB ORM 4 Test Db 4 File Object
  • 56. Mocks• Une « leurre » mais pas besoin d’écrire son code « interne »• Juste décrire ce que l’on attend de lui
  • 57. Mock• Le Mock se contente de bien se « comporter ».• Simulation (Setup)• Vérification du comportement attendu (optionnelle).
  • 58. outillage contratS.U.T.comportement attendu
  • 59. 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
  • 60. 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 cours And je lis le champs ‘Type’ dans la 2e adresse du patient en cours And je lis le champs ‘Type’ dans la 3e adresse du patient en cours• Avec:
  • 61. 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
  • 62. Single Responsibility
  • 63. 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?
  • 64. 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
  • 65. Si mon code est SOLID• Alors mes tests doivent l’être aussi
  • 66. Les CONTRATS sont la clé
  • 67. 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.
  • 68. 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!
  • 69. Tests devenus inutiles: UIPatterns: HUMBLE DIALOG, VISITOR
  • 70. Tester à partir des UI?
  • 71. 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
  • 72. Dans le fluxL’HEURE DU BILAN
  • 73. Avant le BDD
  • 74. Après (dans le flux)
  • 75. Ecriture du test: 5 à 30min
  • 76. Steps• Écriture: 5mn à 2h
  • 77. Steps• Refactoring: 1/2 à 1 journée
  • 78. BILANLa question nest pas: combienje gagne à faire des tests?Mais,combien je perd à chaque bugen prod. #atmrs2012
  • 79. Summary01/06/2010 10/10/2012 - 1:39:45 PM8 Applications livrées (+ 6 logiciels d’installation)Tests running (2x day): 1564, Failures: 0, Inconclusive: 0, Time: 2158 seconds 167 Given, 183 When, 209 ThenSTEPS: 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 monitorSource 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)
  • 80. BÉNÉFICES OBSERVABLES
  • 81. 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
  • 82. 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 ?
  • 83. Mais on est encore très loin du langage naturel• P.O et skateholders ne comprennent (pour l’instant) pas tout.
  • 84. PAG GAPhttps://docs.google.com/viewer?url=http%3A%2F%2Fwww.scrumalliance.org%2Fsystem%2Fslides%2F118%2Foriginal%2FChristianHossa_SpecificationByExampleWithGherkin.pdf%3F1349824954
  • 85. Quest 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).
  • 86. 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 (!)
  • 87. Est ce suffisant pour faire une documentation?
  • 88. 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.
  • 89. DécrireDescriptif n’est pas Impératif
  • 90. C’est s’intéresser à l’essentiel• On ne voit bien quavec le test. Lessentiel est invisible pour les yeux. Antoine de Saint-Test
  • 91. Tests that saves faith
  • 92. Références
  • 93. Pardon• à Antoine de Saint-Exupéry à relire (souvent)
  • 94. BDD dans le flux 2e partieDu Mythe à la réalité
  • 95. TOUT POUR FACILITER LES TESTS
  • 96. Changement de vision
  • 97. Penser le comportementLes vertus de l’abstraction
  • 98. Concevoir un comportement• C’est penser en terme FONCTIONNELS
  • 99. Design émergeant
  • 100. Une affaire de style
  • 101. Changement de style
  • 102. • 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
  • 103. La gravité
  • 104. Dépendances fatales
  • 105. Modèle sans gravité
  • 106. 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)
  • 107. Le Domaine comme modèleagnostique entre les composants
  • 108. Ce que le Domaine n’est pas!• Gestion des états => • Stateless => 
  • 109. Ce que le domaine n’est pas!
  • 110. 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
  • 111. 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.
  • 112. 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
  • 113. 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?
  • 114. 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/
  • 115. LES TESTS D’INTEGRATION SONT ILSUTILES?
  • 116. 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?
  • 117. Du mythe…
  • 118. A la réalité
  • 119. En pratiqueUN ŒIL SUR LES ESPIONS
  • 120. S.U.T Vérification de comportement en parfaite isolation
  • 121. EST ES? BIENT T-IL SSON
  • 122. 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)
  • 123. 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
  • 124. (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)
  • 125. Trucs• Commencer petit• Progresser à son rythme• Refactorer régulièrement• Le temps est votre alliéDRY! KISS! YAGNI! SOLID!
  • 126. Tests that saves faith

×