Le document aborde les raisons pour lesquelles certains développeurs évitent les tests unitaires et propose des solutions pour adopter le développement piloté par les tests (TDD). Il explique des concepts tels que l'injection de dépendance et le bouchonnage pour rendre le code testable, tout en soulignant l'importance de commencer par les tests pour garantir un code fiable et flexible. En conclusion, il encourage vivement à surmonter les excuses et à intégrer les tests dans le processus de développement.

1. Des tests unitaires automatiques ?
Trop cher ! Trop compliqué !
Des recettes pour passer à TDD sans douleur.
Frédéric SCHÄFER
Djamel ZOUAOUI

2. Pourquoi je ne fais pas de tests ?
Plus tard  jamais Pas le temps
Trop cher
Pas testable Sert à rien

3. Objectif de la session
J’ai envie de faire des tests unitaires…
mais je ne sais pas comment m’y prendre !
Et je sais comment m’y prendre !

4. Tordons le cou à ces fausses raisons !
• Je testerai après…
– Parce que je ne sais pas encore comment je vais écrire mon code
– Parce que mon code va évoluer Partie 1
– Parce qu’il faut que je montre quelque chose rapidement
– Parce que je pourrai générer des tests automatiquement / plus facilement
– …
• Ce n’est pas testable parce que …
– Ma classe dépend d’une autre
– Mon code est dans la couche d’interface usager Partie 2
– Mon code doit créer des objets lors de l’exécution
– L’exécution de mon code n’est pas reproductible (dates, hasard,…)
– …

5. Partie 1
• Je testerai après…
– Parce que je ne sais pas encore comment je vais écrire mon code
– Parce que mon code va évoluer
– Parce qu’il faut que je montre quelque chose rapidement
– Parce que je pourrai générer des tests automatiquement / plus facilement
• 2 mois plus tard… : Je n’ai pas eu le temps de tester
• Solution : Commencer par tester (TDD)
Développement
Développement Tests

6. Développement piloté par les tests
• Les tests sont conçus et écrits avant le code applicatif
– Ils représentent l’expression du besoin
– Ils définissent et nouent un contrat de bon fonctionnement de
l’application
Chaque ligne de code est justifiée
par un test qui ne passait pas.

7. Mastermind
Propositions Mal placés
Bien placés
Code Secret

8. On code ?

9. Partie 1 : Conclusion
 (Cassé) – Rouge – Vert – (Remaniement)
 3A : Acteur – Action – Assertion
 1 test vert  1 commit
 1 bug  1 test
 Jouer l’ensemble des tests
 Les tests sont automatisés et rapides

10. 2ème partie
 Ce n’est pas testable parce que …
 Ma classe dépend d’une autre
 L’exécution de mon code n’est pas reproductible
(dates, hasard,…)
 Mon code est dans l’IHM

11. Ma classe dépend d’une autre :
Injection de dépendance
• Les dépendances entre les modules de code peuvent
être définies par un module tiers
– Une classe A ne crée pas l’instance d’une classe B dont elle a
besoin mais utilise une interface IB implémentée par B
– L’implémentation de l’interface IB est fournie à A par un module
tiers
• Respecte le principe de Hollywood
« Ne nous appelez pas, c’est nous qui vous appelons »
– C’est le conteneur qui appelle notre objet pour lui fournir la
dépendance dans notre objet (constructeur / setter) .
– L’objet est en fait passif dans le processus de choix des
dépendances.
– Les dépendances sont sous la responsabilité du conteneur et
non de l’objet.

12. Bouchonnage
• Le bouchonnage d’une classe est la création d’une
classe « similaire » à celle-ci et qui, le cas
échéant, pourra se substituer à elle.
• Cela se formalise par une classe qui se présente comme
la « vraie » classe (même méthodes et propriétés
publiques) mais sur laquelle le développeur a le contrôle.
• Le bouchonnage permet de simuler les données
attendues par une méthode pour son fonctionnement.
• Facilité par l’injection de dépendance !

13. Application à notre Mastermind
Jeu
CodeSecret
NombreDeCoupsJoues
NombreDeCoupsMaximum
StatutActuel
Evalue()
Resultat Jeu() Evaluateur
NbBienPlaces EvalueBienPlaces()
NbMalPlaces EvalueMalPlaces()
Jeu
CodeSecret
NombreDeCoupsJoues
NombreDeCoupsMaximum
StatutActuel
Evalue()
Resultat Jeu(IEvaluateur) IEvaluateur
EvalueBienPlaces()
NbBienPlaces EvalueMalPlaces()
NbMalPlaces
EvaluateurMock Evaluateur
EvalueBienPlaces()
EvalueBienPlaces()
EvalueMalPlaces()
EvalueMalPlaces()

14. On code ?

15. Tests UI : Model-View-ViewModel
• Séparation Présentation – Logique de présentation
UnitTest
View ViewModel Model
DataBinding

16. On code ?

17. La couverture des tests…

18. Conclusion
Pas d’excuses !
• Pour avoir le temps d’écrire les tests, faites du TDD
• On peut (presque) tout tester
Avec TDD je peux...
• mieux documenter le code
– Mon code fait ce qui est décrit dans les tests ni plus, ni moins
• modifier le code sans risque
– (détecter la moindre régression)
• avoir un code flexible
– (non pas générique, mais prêt au changement)

19. Resources
• Test Driven Development - Wikipedia :
http://fr.wikipedia.org/wiki/Test_Driven_Development
• Développement piloté par les tests avec Visual Studio 2005
TeamSystem :
http://download.microsoft.com/download/3/5/7/3574ef99-ba3e-48d6-9fba-
0307742741d9/Programmez-SpecialVSTS-Mars2006.pdf (p. 7)
• Inversion of Control Containers and the Dependency Injection
pattern : http://martinfowler.com/articles/injection.html
• Spring .NET : http://www.springframework.net/
• NMock : http://nmock2.wiki.sourceforge.net/
• Blog OCTO Technology : http://blog.octo.com/
• Podcast « Les tests, pourquoi en faire ? » :
http://www.visualstudiotalkshow.com/Archives/091-28janvier2009-Frederi.html

20. Frédéric SCHÄFER
fschafer@octo.com
+41 79 501 56 76
Djamel ZOUAOUI
dzouaoui@octo.com
+33 6 18 38 47 91