Présentation Alt.net - Tests unitaires automatisés

451 views
376 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
451
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Présentation Alt.net - Tests unitaires automatisés

  1. 1. Des tests unitaires automatiques ? Trop cher ! Trop compliqué !Des recettes pour passer à TDD sans douleur. Frédéric SCHÄFER Djamel ZOUAOUI
  2. 2. Pourquoi je ne fais pas de tests ?Plus tard  jamais Pas le temps Trop cherPas testable Sert à rien
  3. 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. 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. 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. 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. 7. MastermindPropositions Mal placés Bien placés Code Secret
  8. 8. On code ?
  9. 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. 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. 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. 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. 13. Application à notre Mastermind Jeu CodeSecret NombreDeCoupsJoues NombreDeCoupsMaximum StatutActuel Evalue() Resultat Jeu() EvaluateurNbBienPlaces EvalueBienPlaces()NbMalPlaces EvalueMalPlaces() Jeu CodeSecret NombreDeCoupsJoues NombreDeCoupsMaximum StatutActuel Evalue() Resultat Jeu(IEvaluateur) IEvaluateur EvalueBienPlaces()NbBienPlaces EvalueMalPlaces()NbMalPlaces EvaluateurMock Evaluateur EvalueBienPlaces() EvalueBienPlaces() EvalueMalPlaces() EvalueMalPlaces()
  14. 14. On code ?
  15. 15. Tests UI : Model-View-ViewModel• Séparation Présentation – Logique de présentation UnitTest View ViewModel Model DataBinding
  16. 16. On code ?
  17. 17. La couverture des tests…
  18. 18. ConclusionPas d’excuses !• Pour avoir le temps d’écrire les tests, faites du TDD• On peut (presque) tout testerAvec 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. 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. 20. Frédéric SCHÄFERfschafer@octo.com+41 79 501 56 76Djamel ZOUAOUIdzouaoui@octo.com+33 6 18 38 47 91

×