TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 1,673 views

 

Statistics

Views

Total Views
1,673
Views on SlideShare
1,579
Embed Views
94

Actions

Likes
2
Downloads
30
Comments
0

3 Embeds 94

http://ec2-176-34-210-51.eu-west-1.compute.amazonaws.com 82
http://ec2-79-125-29-75.eu-west-1.compute.amazonaws.com 11
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 1. Docteur BDDOu comment j’ai appris à ne plus m’en faire avec les tests (et la doc!)
  • 2. Mercià nos sponsors Platinum
  • 3. Et mercià nos sponsors Gold et Silver
  • 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. TESTER• Je teste• Tu testes• Il ou elle teste• Nous testons• Vous testez• Ils ou elles testent• … mais tu peux pas (tout) test
  • 6. quest ce que je teste?Mon logiciel…
  • 7. Comment je vois mon logiciel
  • 8. De ma vision du logicieldécoule ma vision des tests
  • 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. % Code de l’IHM
  • 11. GOF, ca vous parle?• Humble Dialog• MVC• MVP• MVVM• …
  • 12. Alors, découpons
  • 13. Comment tester cela?
  • 14. On est passé de ca…
  • 15. …à cà!
  • 16. Et puis on m’a parlé de services…
  • 17. Alors j’ai découpé en services
  • 18. Ca me rappelle …
  • 19. Heureusement, je travaille chez
  • 20. J’ai voulu tester les « services »
  • 21. Mais un service c’est pas simple• Les dépendances m’ont tuer!
  • 22. A l’intérieur…
  • 23. Ce que je teste, je l’éclaire
  • 24. Ce que je teste, je le nomme
  • 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. Tester à partir des UI?
  • 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. 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. 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. Un seul principe
  • 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. Tester c’est comprendre• du latin « comprehensio »1, de « cum », avec, et « prehendere », prendre: action de saisir ensemble ou de prendre avec soi
  • 33. Comprendre quoi?• .. Comment ca marche (à l’intérieur) – Ou bien• Comment ça se comporte (de l’extérieur)
  • 34. Le Test Comportementaliste
  • 35. Le réserver aux IHM?• Pourquoi n’y aurait-il que les IHM qui ont un comportement?
  • 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. Qui observe quoi?
  • 38. On a bien dit « automatiser le test »• L’observateur est donc un programme …un automate
  • 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. Simplifier = Isoler
  • 41. Une chose à la fois
  • 42. Single Responsibility
  • 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. Si mon code est SOLID• Alors mes tests doivent l’être aussi
  • 45. Un exemple• Et maintenant, un peu de vrai code
  • 46. Ce que m’apporte la forme BDDT.U. classique T.U. Behavioriste• ARRANGE • GIVEN• ACT • WHEN• ASSERT • THEN
  • 47. Je passe au BDD• Je passe à une description textuelle• Exemple!
  • 48. DRY• Mes tests aussi !• Refactoring• Les Steps c’est beaucoup de DRY• Exemple!
  • 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. Les incontournables• de la refactorisation : – Dummies / Doublures – Fake – Mocks – Stub – Espions – Helpers
  • 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. 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. Est ce suffisant pour faire une documentation?
  • 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. Est-ce que tester "à ce point" modifie ma conception logicielle? (design émergeant)
  • 56. Oui, et de 2 façons
  • 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. Penser le comportementLes vertus de l’abstraction
  • 59. DécrireDescriptif n’est pas Impératif
  • 60. Un comportement attendu est vérifiable à coup sur
  • 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. 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. Concevoir un comportement• C’est penser en terme FONCTIONNELS
  • 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. 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. 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. 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. Références
  • 69. Pardon• à Antoine de Saint-Exupéry à relire (souvent)
  • 70. Questions ?