0
BDD BDD BDD TDD BDD ATDD BDD AATDD BDD DDD BDD AUT BDD UET
 
 
la langue....
 
<ul><li>http://www.ldolphin.org/babel.html </li></ul>
<ul><li>to talk effectively with our customers we need to learn and use their language </li></ul>
William S. Burroughs <ul><li>language is a virus from outer space </li></ul>
de quoi parlons nous?
MISE AU POINT  
 
 
 
si les tests dirigent le projet...  
...qui dirige les tests?
TOP DOWN or BOTTOM UP? http://kinderman.net/articles/2007/11/18/testing-on-high-bottom-up-versus-top-down-test-driven-deve...
TDD top-down   < =>  donne moi plus d'abstraction      TDD bottom-up < = > donne moi plus de contrôle Outside-In  < = >  r...
Par quoi on commence? <ul><ul><li>MIDDLE-OUT en pratique </li></ul></ul><ul><ul><ul><li>le PO et le DEV se parlent ! </li>...
http://www.2ia.net/user-story/
largement insuffisant pour le développeur <ul><ul><li>trop flou! </li></ul></ul><ul><ul><ul><li>quasi-impossible d'écrire ...
TDD est pourtant la technique la plus efficace <ul><ul><li>TEST FIRST + REFACTORING = </li></ul></ul><ul><ul><ul><li>  </l...
  Qui veut tester ? Acceptance / PO  je veux le vérifier à l'écran Technique / DEV je veux le vérifier dans le code
Expliquez, explicitez
Ecrire façon Gherkin <ul><ul><li>Story =>  Feature </li></ul></ul><ul><ul><li>Scenario/Story Tests =>  Steps </li></ul></u...
Ecrire les Critères d'Acceptation <ul><ul><li>Story Test / BDD Scenario </li></ul></ul><ul><ul><ul><li>Given </li></ul></u...
Natural steps / des étapes naturelles <ul><li>BDD (Scenario)‏ </li></ul><ul><ul><li>Given </li></ul></ul><ul><ul><li>When ...
le test manuel est immoral   http://blog.objectmentor.com/articles/2007/10/17/tdd-with-acceptance-tests-and-unit-tests
 
Agile Acceptance Test-Driven Development <ul><li><=> </li></ul><ul><li>  Requirements As Executable Tests </li></ul>
Automated   Executable  Tests  <ul><li>User  Acceptance Testing  (UAT)  </li></ul><ul><li>  http://en.wikipedia.org/wiki/L...
mais il faut apprendre <ul><li>idée: prenez un coach ;)‏ </li></ul>
A quoi cela ressemble? <ul><li>Acceptance GUI </li></ul><ul><li>« Technical » Unit Test </li></ul>
Comment ca marche?
Comment ca marche?
Isolation Make it clear
Agile Strategy Brian Marick http://www.exampler.com/testing-com/agile/
Problèmes des Scénarios &quot;d'en bas&quot; <ul><li>écrits par les développeurs </li></ul><ul><li>  </li></ul><ul><li>tro...
Problèmes des Scénarios &quot;d'en haut&quot; <ul><li>  écrits par le product owner </li></ul><ul><li>  </li></ul><ul><li>...
le haut et le bas toujours ensemble
Qui teste qui? <ul><li>les TU techniques vérifient-ils les TA? </li></ul><ul><li>les steps techniques vérifient des règles...
Quelques Conclusions  
<ul><li>EXPLICITER  POUR  TESTER  LE  </li></ul><ul><li>COMPORTEMENT </li></ul><ul><li>c'est lever l'ambiguité du langage ...
les Tests sont les Specs <ul><li>BDD </li></ul><ul><li>Behaviour = Comportement </li></ul><ul><li>Spécifier le Comportemen...
<ul><li>le TEST COMPORTEMENTALISTE  c'est maintenant </li></ul><ul><li>et pour  TOUTE l'équipe </li></ul><ul><li>ce n'est ...
<ul><li>tester rend  </li></ul><ul><li>HUMBLE </li></ul>
Questions?  
Definition of Done Everything is GREEEEEEN! (but first it needs to be RED)‏ TDD : 100% code coverage! ATDD : mesure manuel...
 
 
Upcoming SlideShare
Loading in...5
×

to Test or not to Test?

1,933

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,933
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • est la meilleure
  • et la pire des choses
  • OUTISDE IN   cumule également les travers des deux approches , notamment en induisant un très fort risque d’effet tunnel. En effet, le point critique de cette démarche est l’étape d’accostage. MIDDLE OUT Par opposition à l’approche Outside In, cette méthode propose de commencer « In the middle », c’est-à-dire là où le métier et les IT parlent le même langage (ou en tout cas presque). Elle s’attaque donc d’emblée à ce qui reste un des principaux freins à l’adoption des BDD au sein des équipes françaises : La  compréhension du métier  par la Task Force  et inversement, la  compréhension des contraintes tech par le PO et stakeholder .
  • faire se rencontrer le haut et le bas User Stories made by the dev team the product owner How they can converge? 
  • Transcript of "to Test or not to Test?"

    1. 1. BDD BDD BDD TDD BDD ATDD BDD AATDD BDD DDD BDD AUT BDD UET
    2. 4. la langue....
    3. 5.  
    4. 6. <ul><li>http://www.ldolphin.org/babel.html </li></ul>
    5. 7. <ul><li>to talk effectively with our customers we need to learn and use their language </li></ul>
    6. 8. William S. Burroughs <ul><li>language is a virus from outer space </li></ul>
    7. 9. de quoi parlons nous?
    8. 10. MISE AU POINT  
    9. 14. si les tests dirigent le projet...  
    10. 15. ...qui dirige les tests?
    11. 16. TOP DOWN or BOTTOM UP? http://kinderman.net/articles/2007/11/18/testing-on-high-bottom-up-versus-top-down-test-driven-development  
    12. 17. TDD top-down   < => donne moi plus d'abstraction      TDD bottom-up < = > donne moi plus de contrôle Outside-In  < = >  rendez vous au point de convergence Middle-Out  < = >  partons du point de convergence
    13. 18. Par quoi on commence? <ul><ul><li>MIDDLE-OUT en pratique </li></ul></ul><ul><ul><ul><li>le PO et le DEV se parlent ! </li></ul></ul></ul><ul><ul><ul><li>http://www.slideshare.net/josephwilk/outsidein-development-with-cucumber-and-rspec </li></ul></ul></ul><ul><ul><li>  Business Readeable Domain Specific Language  ? </li></ul></ul><ul><li>http://martinfowler.com/bliki/BusinessReadableDSL.html </li></ul>
    14. 19. http://www.2ia.net/user-story/
    15. 20. largement insuffisant pour le développeur <ul><ul><li>trop flou! </li></ul></ul><ul><ul><ul><li>quasi-impossible d'écrire du code en approche TDD </li></ul></ul></ul><ul><ul><ul><li>par quel bout commencer? </li></ul></ul></ul><ul><ul><ul><li>vertige de la page blanche pour le développeur </li></ul></ul></ul><ul><ul><li>Test First </li></ul></ul><ul><ul><ul><li>il faut des tests techniques unitaires très simples qui aboutissent au code </li></ul></ul></ul><ul><ul><ul><li>il faut une conception simple </li></ul></ul></ul>
    16. 21. TDD est pourtant la technique la plus efficace <ul><ul><li>TEST FIRST + REFACTORING = </li></ul></ul><ul><ul><ul><li>  </li></ul></ul></ul><ul><ul><ul><ul><li>conception simplifiée </li></ul></ul></ul></ul><ul><ul><ul><li>  </li></ul></ul></ul><ul><ul><ul><ul><li>0 bugs </li></ul></ul></ul></ul><ul><ul><ul><li>  </li></ul></ul></ul><ul><ul><ul><ul><li>intention du code très claire (relecture et correction facilitée)‏ </li></ul></ul></ul></ul><ul><ul><ul><li>  </li></ul></ul></ul><ul><ul><ul><ul><li>100% de couverture de code par les tests =>FIABILITE </li></ul></ul></ul></ul><ul><ul><ul><li>  </li></ul></ul></ul>
    17. 22.   Qui veut tester ? Acceptance / PO  je veux le vérifier à l'écran Technique / DEV je veux le vérifier dans le code
    18. 23. Expliquez, explicitez
    19. 24. Ecrire façon Gherkin <ul><ul><li>Story => Feature </li></ul></ul><ul><ul><li>Scenario/Story Tests => Steps </li></ul></ul><ul><li>Business Redeable Domain Specific Language  ! </li></ul><ul><li>http://wiki.github.com/aslakhellesoy/cucumber/gherkin </li></ul>
    20. 25. Ecrire les Critères d'Acceptation <ul><ul><li>Story Test / BDD Scenario </li></ul></ul><ul><ul><ul><li>Given </li></ul></ul></ul><ul><ul><ul><ul><li>(And)‏ </li></ul></ul></ul></ul><ul><ul><ul><li>When </li></ul></ul></ul><ul><ul><ul><li>(And)‏ </li></ul></ul></ul><ul><ul><ul><li>Then </li></ul></ul></ul><ul><ul><ul><ul><li>(And)‏ </li></ul></ul></ul></ul>
    21. 26. Natural steps / des étapes naturelles <ul><li>BDD (Scenario)‏ </li></ul><ul><ul><li>Given </li></ul></ul><ul><ul><li>When </li></ul></ul><ul><ul><li>Then </li></ul></ul><ul><li>TDD </li></ul><ul><ul><li>Arrange </li></ul></ul><ul><ul><li>Act </li></ul></ul><ul><ul><li>Assert </li></ul></ul>
    22. 27. le test manuel est immoral   http://blog.objectmentor.com/articles/2007/10/17/tdd-with-acceptance-tests-and-unit-tests
    23. 29. Agile Acceptance Test-Driven Development <ul><li><=> </li></ul><ul><li>  Requirements As Executable Tests </li></ul>
    24. 30. Automated Executable Tests  <ul><li>User Acceptance Testing (UAT) </li></ul><ul><li>  http://en.wikipedia.org/wiki/List_of_GUI_testing_tools </li></ul><ul><li>Selenium </li></ul><ul><li>Watin.... </li></ul><ul><li>... </li></ul><ul><li>Teste la V </li></ul><ul><li>Teste l'intégration totale (repository, SGBDR, WS, services et systèmes tiers)‏ </li></ul><ul><li>  </li></ul><ul><li>jouables dans </li></ul><ul><li>les </li></ul><ul><li>les Nightly Build </li></ul><ul><li>Executable Unit Testing (EUT)‏ </li></ul><ul><li>  [Gerkin based] </li></ul><ul><li>Fitness / Cucumber / Specflow / RSpec / Concordion... </li></ul><ul><li>.... </li></ul><ul><li>Teste le M+C </li></ul><ul><li>Teste les BO </li></ul><ul><li>Teste avec des Mocks </li></ul><ul><li>  ... </li></ul><ul><li>jouables dans tous les builds </li></ul>
    25. 31. mais il faut apprendre <ul><li>idée: prenez un coach ;)‏ </li></ul>
    26. 32. A quoi cela ressemble? <ul><li>Acceptance GUI </li></ul><ul><li>« Technical » Unit Test </li></ul>
    27. 33. Comment ca marche?
    28. 34. Comment ca marche?
    29. 35. Isolation Make it clear
    30. 36. Agile Strategy Brian Marick http://www.exampler.com/testing-com/agile/
    31. 37. Problèmes des Scénarios &quot;d'en bas&quot; <ul><li>écrits par les développeurs </li></ul><ul><li>  </li></ul><ul><li>trop techniques </li></ul><ul><li>vision du développeur seulement </li></ul><ul><li>pas assez proche des utilisateurs </li></ul><ul><li>ne reflète pas forcement le produit final </li></ul><ul><li>pas forcement en adéquation avec ce que veux le PO </li></ul><ul><li>  </li></ul><ul><li>... mais elles sont nécessaires car elles sont l'implémentation qui marche!  </li></ul><ul><li>... et ils dirigent l'écriture du code </li></ul>
    32. 38. Problèmes des Scénarios &quot;d'en haut&quot; <ul><li>  écrits par le product owner </li></ul><ul><li>  </li></ul><ul><li>trop abstraits, pas assez détaillés parfois </li></ul><ul><li>vision qui ne tient pas compte des possibilités/restrictions de la technique </li></ul><ul><li>pas assez proche du rendu du produit final </li></ul><ul><li>pas forcement ce que peux faire le dev </li></ul><ul><li>  </li></ul><ul><li>... mais ils sont une expression (ajustable) de ce que veux le client! </li></ul>
    33. 39. le haut et le bas toujours ensemble
    34. 40. Qui teste qui? <ul><li>les TU techniques vérifient-ils les TA? </li></ul><ul><li>les steps techniques vérifient des règles qui sont explicitées dans les TA, mais aussi d'autres inventées par le dev </li></ul><ul><li>  </li></ul><ul><li>les TA vérifient-ils les TU? </li></ul><ul><li>normalement le test d'intégration vérifie qu'en lancant les TA, les TU sont vérifiés </li></ul><ul><li>mais seuls sont joués les STEPS d'acceptance </li></ul><ul><li>comment garantir la complétude TA / TU ? </li></ul>
    35. 41. Quelques Conclusions  
    36. 42. <ul><li>EXPLICITER POUR TESTER LE </li></ul><ul><li>COMPORTEMENT </li></ul><ul><li>c'est lever l'ambiguité du langage </li></ul><ul><li>( « désambiguïsation  »)‏ </li></ul>
    37. 43. les Tests sont les Specs <ul><li>BDD </li></ul><ul><li>Behaviour = Comportement </li></ul><ul><li>Spécifier le Comportement = cahier des charges   </li></ul><ul><li>Acceptance = critère d'acceptation du comportement attendu </li></ul>
    38. 44. <ul><li>le TEST COMPORTEMENTALISTE c'est maintenant </li></ul><ul><li>et pour TOUTE l'équipe </li></ul><ul><li>ce n'est pas une affaire de gurus ou d'experts </li></ul><ul><li>les outils sont là, gratuits et vite intégrés </li></ul><ul><li>faites vous aider... </li></ul>
    39. 45. <ul><li>tester rend </li></ul><ul><li>HUMBLE </li></ul>
    40. 46. Questions?  
    41. 47. Definition of Done Everything is GREEEEEEN! (but first it needs to be RED)‏ TDD : 100% code coverage! ATDD : mesure manuelles :'( autres idées?
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×