Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

to Test or not to Test?

2 448 vues

Publié le

Publié dans : Technologie, Formation
  • Soyez le premier à commenter

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?

×