1. Docteur
BDD
Ou 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. qu'est ce que je teste?
Mon logiciel…

7. Comment je vois mon logiciel

8. De ma vision du logiciel
dé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)

35. Le Test Comportementaliste

36. Le réserver aux IHM?
• Pourquoi n’y aurait-il que les IHM qui ont un
comportement?

37. Qu’est ce qu’un comportement?
• Le comportement d'un ê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

38. Qui observe quoi?

39. On a bien dit « automatiser
le test »
• L’observateur est donc un programme
…un automate

40. 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

41. Simplifier = Isoler

42. Une chose à la fois

43. Single Responsibility

44. 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

45. Si mon code est SOLID
• Alors mes tests doivent l’être aussi

46. Un exemple
• Et maintenant, un peu de vrai code

47. Ce que m’apporte la forme BDD
T.U. classique T.U. Behavioriste
• ARRANGE • GIVEN
• ACT • WHEN
• ASSERT • THEN

48. Je passe au BDD
• Je passe à une description textuelle
• Exemple!

49. DRY
• Mes tests aussi !
• Refactoring
• Les Steps c’est beaucoup de DRY
• Exemple!

50. 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!

51. Les incontournables
• de la refactorisation :
– Dummies / Doublures
– Fake
– Mocks
– Stub
– Espions
– Helpers

52. 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

53. Qu'est 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)

54. Est ce suffisant pour faire
une documentation?

55. • 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

56. Est-ce que tester "à ce point" modifie
ma conception logicielle?
(design émergeant)

57. Oui, et de 2 façons

58. 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

59. Penser le comportement
Les vertus de
l’abstraction

60. Décrire
Descriptif n’est pas Impératif

61. Un comportement attendu
est vérifiable à coup sur

62. 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)

63. 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

64. Concevoir un comportement
• C’est penser en terme FONCTIONNELS

65. C’est s’interesser à l’essentiel
• On ne voit bien qu'avec le test. L'essentiel est
invisible pour les yeux.
Antoine de Saint-Test

66. 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.

67. 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

68. 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?

69. Références

71. Pardon
• à Antoine de Saint-Exupéry
à relire (souvent)

72. Questions ?