TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)

2,220 views

Published on

Published in: Technology

TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)

  1. 1. Docteur BDDOu comment j’ai appris à ne plus m’en faire avec les tests (et la doc!)
  2. 2. Mercià nos sponsors Platinum
  3. 3. Et mercià nos sponsors Gold et Silver
  4. 4. Guillaume Saint Etienne• Développeur Senior .Net• Artisan Logiciel / Software Craftsman• J’ai également été Architecte, Chef de Projet, Scrum Master, Responsable d’Activité• http://dotnetguru2.org/gse• http://groups.google.com/group/craftsmen- france-• Twitter : @guillaume_agile
  5. 5. TESTER• Je teste• Tu testes• Il ou elle teste• Nous testons• Vous testez• Ils ou elles testent• … mais tu peux pas (tout) test
  6. 6. quest ce que je teste?Mon logiciel…
  7. 7. Comment je vois mon logiciel
  8. 8. De ma vision du logicieldécoule ma vision des tests
  9. 9. Acceptance = IHM?• Et les règles métier?• Et le stockage?• Et les transmissions/flux?• Les transactions? les services externes?• La gestion des erreurs, des mises à jour… Faut-il à chaque fois que je lance tout mon logiciel pour n’en tester qu’une partie???
  10. 10. % Code de l’IHM
  11. 11. GOF, ca vous parle?• Humble Dialog• MVC• MVP• MVVM• …
  12. 12. Alors, découpons
  13. 13. Comment tester cela?
  14. 14. On est passé de ca…
  15. 15. …à cà!
  16. 16. Et puis on m’a parlé de services…
  17. 17. Alors j’ai découpé en services
  18. 18. Ca me rappelle …
  19. 19. Heureusement, je travaille chez
  20. 20. J’ai voulu tester les « services »
  21. 21. Mais un service c’est pas simple• Les dépendances m’ont tuer!
  22. 22. A l’intérieur…
  23. 23. Ce que je teste, je l’éclaire
  24. 24. Ce que je teste, je le nomme
  25. 25. Ce que je teste, je l’explicite• Je dis clairement et simplement ce que j’attends, moi développeur.• Ce que j’attends comme comportement, c’est ce qui va œuvrer (et qui est indispensable pour) le bon fonctionnement de l’ensemble.• Comment mon client pourrait-il être satisfait de l’ensemble, si chaque pièce ne fonctionne pas de manière irréprochable?
  26. 26. Tester à partir des UI?
  27. 27. Alors, (re)disons le• Tester « tout » et « à la fin » : CA NE MARCHE PAS!• Le BDD pour l’Acceptance Testing est une ARNAQUE! (Integration/Integrated Tests)• Car les scénarios sont d’une complexité exponentielle, vous n’y arriverez pas!• Laissez tomber Selenium! (on en reparle) http://www.jbrains.ca/permalink/integrated-tests-are-a- scam-part-1
  28. 28. Pourquoi abandonner ATDD• Si « Humble Dialog » est bien appliqué,• tester sur l’UI revient à tester le navigateur Web ou Winform/WPF ou JFC/Swing ou ….• (too much) code in the UI = it smells• Integrated Tests are a scam!
  29. 29. 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
  30. 30. Un seul principe
  31. 31. KISS• Keep it simple, stupid!• Ce que l’on teste bien s’énonce clairement – (ou comment ne pas boire la tasse quand on cite Boileau)• Simple = Unique, seul
  32. 32. Tester c’est comprendre• du latin « comprehensio »1, de « cum », avec, et « prehendere », prendre: action de saisir ensemble ou de prendre avec soi
  33. 33. Comprendre quoi?• .. Comment ca marche (à l’intérieur) – Ou bien• Comment ça se comporte (de l’extérieur)
  34. 34. Le Test Comportementaliste
  35. 35. Le réserver aux IHM?• Pourquoi n’y aurait-il que les IHM qui ont un comportement?
  36. 36. Qu’est ce qu’un comportement?• Le comportement dun être vivant et, plus généralement, de tout autre système est la partie de son activité qui se manifeste à un observateur• http://fr.wikipedia.org/wiki/Comportement
  37. 37. Qui observe quoi?
  38. 38. On a bien dit « automatiser le test »• L’observateur est donc un programme …un automate
  39. 39. La chose observée• est un bout de code.• Doit être: – Simplifiée pour mieux comprendre – Simplifiée pour tester plus vite – Simplifiée pour avoir un résultat plus rapidement – Simplifiée pour rechercher les problèmes plus simplement.• Le test lui-même doit rester simple
  40. 40. Simplifier = Isoler
  41. 41. Une chose à la fois
  42. 42. Single Responsibility
  43. 43. 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
  44. 44. Si mon code est SOLID• Alors mes tests doivent l’être aussi
  45. 45. Un exemple• Et maintenant, un peu de vrai code
  46. 46. Ce que m’apporte la forme BDDT.U. classique T.U. Behavioriste• ARRANGE • GIVEN• ACT • WHEN• ASSERT • THEN
  47. 47. Je passe au BDD• Je passe à une description textuelle• Exemple!
  48. 48. DRY• Mes tests aussi !• Refactoring• Les Steps c’est beaucoup de DRY• Exemple!
  49. 49. Exemple de refactoring• Je vais gagner énormément de temps• Fini le copier/coller… dans le code !• Donc fini les erreurs…. sur le code (technique) des tests!• Exemple!
  50. 50. Les incontournables• de la refactorisation : – Dummies / Doublures – Fake – Mocks – Stub – Espions – Helpers
  51. 51. Mes tests peuvent être lus• Ce n’est plus du code, c’est du texte!!• C’est ca qui change tout• Je peux les échanger• Quelqu’un de non technique pourrait les écrire
  52. 52. 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)
  53. 53. Est ce suffisant pour faire une documentation?
  54. 54. • Si c’est bien raconté, oui.• Pèsera autant qu’un lourd cahier de tests.• J’ai gagné des semaines (voir des mois) hommes de travail de rédaction et de vérifications.• Export automatique -> Html, Word, Pdf
  55. 55. Est-ce que tester "à ce point" modifie ma conception logicielle? (design émergeant)
  56. 56. Oui, et de 2 façons
  57. 57. Penser le test en premier• BDD = TDD• Test First• Anticiper plutôt que guérir• 40 à 90% de code défectueux en moins• 15 à 35% de temps supplémentaire au début du projet (seulement)• Vous connaissez le cout de la correction après développement ou de la TMA…. donc... – http://www.infoq.com/news/2009/03/TDD-Improves-Quality
  58. 58. Penser le comportementLes vertus de l’abstraction
  59. 59. DécrireDescriptif n’est pas Impératif
  60. 60. Un comportement attendu est vérifiable à coup sur
  61. 61. 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)
  62. 62. 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
  63. 63. Concevoir un comportement• C’est penser en terme FONCTIONNELS
  64. 64. C’est s’interesser à l’essentiel• On ne voit bien quavec le test. Lessentiel est invisible pour les yeux. Antoine de Saint-Test
  65. 65. Incidences sur le code• Penser d’abord des Interfaces qui décrivent le comportement tels que les tests ont pu les expliciter dans des scénarios mettant en évidence la valeur ajoutée du fonctionnement choisi.• Ecrire les tests qui détaille les scénarios du comportement à observer.• Ecrire l’implémentation.• Vérifier.
  66. 66. 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
  67. 67. 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?
  68. 68. Références
  69. 69. Pardon• à Antoine de Saint-Exupéry à relire (souvent)
  70. 70. Questions ?

×