to Test or not to Test?

2 259 vues

Publié le

Publié dans : Technologie, Formation
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 259
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
34
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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? 
  • 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?

    ×