201001 TDD

559 views

Published on

by Laurent Caron

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
559
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

201001 TDD

  1. 1. Le développement piloté par les tests Laurent CARON – lcaron@interfaces-solutions.fr 1
  2. 2. A l’école on m’a appris… 2
  3. 3. LE CYCLE EN V… Exigences Tests fonctionnels Analyse Tests d’intégration Conception Tests unitaires Implémentationmar avr mai jui juil aou sep oct nov dec jan 3
  4. 4. ET CA FONCTIONNE ?Bien sûr, si on a des spécificationsimpeccables, limpides et lisibles… 4
  5. 5. ET CA FONCTIONNE ?Par un client qui sait ce qui veut… 5
  6. 6. ET CA FONCTIONNE ?Et une équipe de développeurs en bétonqui respectent les délais 6
  7. 7. ET DANS LA VRAIE VIE ?Les spécifications arrivent en retard…Sont retouchées…Le développement a été refait 18 fois !Pour tenir à peu près les délais, on rogneun peu sur les tests…Puis beaucoup…On recette sur une version bêtaPuis on croise les doigts à chaque livraison 7
  8. 8. DEVELOPMENT HELL Augmentation de la pressionBaisse de la Moins de temps pourproductivité écrire les tests Code moins stable 8
  9. 9. EN PLUS… Ce n’est la faute de personneExpression des besoins Spécifications Codage Cahier de tests BUG ! Tests 9
  10. 10. EN PLUS… Ce n’est la faute de personneExpression des besoins Spécifications C’est leur faute ! Codage Cahier de tests Tests 10
  11. 11. EN PLUS… Ce n’est la faute de personneExpression des besoins C’est mal spécifié ! Spécifications Codage Cahier de tests Tests 11
  12. 12. EN PLUS… Si, c’est celle du client !Expression des besoins C’est mal exprimé ! Spécifications Codage Cahier de tests Voici le règne des avenants ! Tests 12
  13. 13. UNE SEULE SOLUTION 13
  14. 14. Et pourquoi pas autre chose ? 14
  15. 15. LE DÉVELOPPEMENT PILOTÉ PAR LES TESTS On écrit les tests AVANT le code Déroulement : Ecriture du test Vérification de léchec du test (puisque le code nexiste pas encore) Ecriture du code Vérification du test Refactoring (amélioration en gardant les mêmes fonctionnalités) : javadoc, commentaires… 15
  16. 16. LE DÉVELOPPEMENT PILOTÉ PAR LES TESTS Codage du test Refactor Compilation Lancement du test Correction des Jusqu’à ce qu’il passe erreurs de compilation Lancement du test Ecriture du code échec 16
  17. 17. INTÉRÊTPrécisent les spécificationsForce à réfléchir très tôt aux jeux de testPermet darrêter le travail au bon moment(quand les tests passent) Par conséquent, la conception est meilleure 17
  18. 18. INTÉRÊTLe code produit est testableTest de composants en couche sans avoir besoin descouches de présentationAutomatisation et non-régressionRefactoring aisé Confiance dans le code 18
  19. 19. Ce n’est pas seulement une technique… 19
  20. 20. DANS LES PROJETS INFORMATIQUES…On rencontre principalement 3 typesdintervenants Ceux qui « spécifient » Ceux qui « codent » Ceux qui « testent »Mais, la plupart du temps… Ils ne parlent pas le même langage Ils ne travaillent pas ensemble Ils ne se connaissent parfois même pas 20
  21. 21. QUE FAIRE ?Il faut les aider… à travailler ensemble à rendre le travail de chacun utile à se sentir ensemble dans cette aventure 21
  22. 22. QUE FAIRE ?Spécifier les comportements avec desexemplesLier les spécifications au code deproductionEcrire des tests avant le codeEchanger des idées en écrivant des testsPartager un résultat attendu avant decoder 22
  23. 23. QUE FAIRE ?Faire des tests les vedettes de votre projetSe mettre daccord sur ce que lon veut puiscoderCapitaliser les conversations dans des testsDocumenter lutilisation dun code dansdes tests 23
  24. 24. BONNES PRATIQUESTests PetitsTests IsolésFonctionnant sous nimporte quel environnementTests CompletsTests RépétablesTests AutomatiquesTests Clairs pour tout le mondeConcevoir les tests comme des spécifications, pascomme des vérifications 24
  25. 25. Et comment faire avec du code existant ? 25
  26. 26. LE CODE EXISTANT…Il n’y a pas de testCe code n’a pas été conçu pour qu’on puisseécrire simplement des testsPar où je commence ? 26
  27. 27. ON ÉCRIT LE TEST POUR TOUT LE CODE ? Le projet est gros, il faut donc passer les 6 prochains mois à écrire des tests Evidemment, ce n’est pas réaliste ! Commençons petit ! 27
  28. 28. ON COMMENCE PAR 1 TEST !Cherchez une portion de code testable (classe,méthode, fonction…)Ecrivez un test qui porte sur cette portionLancez-le : il doit réussir(enfin, normalement ☺)Ecrivez un test par jour… 28
  29. 29. TESTEZ À CHAQUE MODIFICATION DU CODE La prochaine fois que vous devez corriger un bug, écrivez un test qui permet de reproduire ce problème… Et qui échoue ! Si la portion de code n’est pas testable, modifier le code pour l’isoler et la tester ! 29
  30. 30. LANCEZ VOS TESTS !Quand vous avez écrit vos tests, vous devezles lancer !Si vous ne le faites pas, ils sont inutiles…Et c’est mieux si vous les faites exécuterautomatiquement… 30
  31. 31. LES DÉFAUTS DE L’APPROCHE TDDCoûteux en tempsParfois complexe àconcevoirPeut sembler peu utilecar le développeur doitenvisager tous les cas defigure, même ceux apriori inutiles 31

×