Le document traite des différents types de tests en développement logiciel, notamment le Test Driven Development (TDD) et le Behaviour Driven Development (BDD), en mettant en avant l'importance d'une communication efficace entre développeurs et clients pour définir les critères d'acceptation. Il souligne les défis liés aux scénarios de tests écrits par les développeurs et les product owners et propose des solutions pour assurer la complétude des tests. Enfin, il insiste sur le fait que tester est une responsabilité collective, nécessitant l'implication de toute l'équipe.

1. BDD BDD BDD TDD BDD ATDD BDD AATDD BDD DDD BDD AUT BDD UET

4. la langue....

6. http://www.ldolphin.org/babel.html

7. to talk effectively with our customers we need to learn and use their language

8. William S. Burroughs language is a virus from outer space

9. de quoi parlons nous?

10. MISE AU POINT

14. si les tests dirigent le projet...

15. ...qui dirige les tests?

16. TOP DOWN or BOTTOM UP? http://kinderman.net/articles/2007/11/18/testing-on-high-bottom-up-versus-top-down-test-driven-development

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

18. Par quoi on commence? MIDDLE-OUT en pratique le PO et le DEV se parlent ! http://www.slideshare.net/josephwilk/outsidein-development-with-cucumber-and-rspec Business Readeable Domain Specific Language ? http://martinfowler.com/bliki/BusinessReadableDSL.html

19. http://www.2ia.net/user-story/

20. largement insuffisant pour le développeur trop flou! quasi-impossible d'écrire du code en approche TDD par quel bout commencer? vertige de la page blanche pour le développeur Test First il faut des tests techniques unitaires très simples qui aboutissent au code il faut une conception simple

21. TDD est pourtant la technique la plus efficace TEST FIRST + REFACTORING = conception simplifiée 0 bugs intention du code très claire (relecture et correction facilitée)‏ 100% de couverture de code par les tests =>FIABILITE

22. Qui veut tester ? Acceptance / PO je veux le vérifier à l'écran Technique / DEV je veux le vérifier dans le code

23. Expliquez, explicitez

24. Ecrire façon Gherkin Story => Feature Scenario/Story Tests => Steps Business Redeable Domain Specific Language ! http://wiki.github.com/aslakhellesoy/cucumber/gherkin

25. Ecrire les Critères d'Acceptation Story Test / BDD Scenario Given (And)‏ When (And)‏ Then (And)‏

26. Natural steps / des étapes naturelles BDD (Scenario)‏ Given When Then TDD Arrange Act Assert

27. le test manuel est immoral http://blog.objectmentor.com/articles/2007/10/17/tdd-with-acceptance-tests-and-unit-tests

29. Agile Acceptance Test-Driven Development <=> Requirements As Executable Tests

30. Automated Executable Tests User Acceptance Testing (UAT) http://en.wikipedia.org/wiki/List_of_GUI_testing_tools Selenium Watin.... ... Teste la V Teste l'intégration totale (repository, SGBDR, WS, services et systèmes tiers)‏ jouables dans les les Nightly Build Executable Unit Testing (EUT)‏ [Gerkin based] Fitness / Cucumber / Specflow / RSpec / Concordion... .... Teste le M+C Teste les BO Teste avec des Mocks ... jouables dans tous les builds

31. mais il faut apprendre idée: prenez un coach ;)‏

32. A quoi cela ressemble? Acceptance GUI « Technical » Unit Test

33. Comment ca marche?

34. Comment ca marche?

35. Isolation Make it clear

36. Agile Strategy Brian Marick http://www.exampler.com/testing-com/agile/

37. Problèmes des Scénarios &quot;d'en bas&quot; écrits par les développeurs trop techniques vision du développeur seulement pas assez proche des utilisateurs ne reflète pas forcement le produit final pas forcement en adéquation avec ce que veux le PO ... mais elles sont nécessaires car elles sont l'implémentation qui marche! ... et ils dirigent l'écriture du code

38. Problèmes des Scénarios &quot;d'en haut&quot; écrits par le product owner trop abstraits, pas assez détaillés parfois vision qui ne tient pas compte des possibilités/restrictions de la technique pas assez proche du rendu du produit final pas forcement ce que peux faire le dev ... mais ils sont une expression (ajustable) de ce que veux le client!

39. le haut et le bas toujours ensemble

40. Qui teste qui? les TU techniques vérifient-ils les TA? les steps techniques vérifient des règles qui sont explicitées dans les TA, mais aussi d'autres inventées par le dev les TA vérifient-ils les TU? normalement le test d'intégration vérifie qu'en lancant les TA, les TU sont vérifiés mais seuls sont joués les STEPS d'acceptance comment garantir la complétude TA / TU ?

41. Quelques Conclusions

42. EXPLICITER POUR TESTER LE COMPORTEMENT c'est lever l'ambiguité du langage ( « désambiguïsation »)‏

43. les Tests sont les Specs BDD Behaviour = Comportement Spécifier le Comportement = cahier des charges Acceptance = critère d'acceptation du comportement attendu

44. le TEST COMPORTEMENTALISTE c'est maintenant et pour TOUTE l'équipe ce n'est pas une affaire de gurus ou d'experts les outils sont là, gratuits et vite intégrés faites vous aider...

45. tester rend HUMBLE

46. Questions?

47. Definition of Done Everything is GREEEEEEN! (but first it needs to be RED)‏ TDD : 100% code coverage! ATDD : mesure manuelles :'( autres idées?