Le développement piloté par les            tests     Laurent CARON – lcaron@interfaces-solutions.fr                       ...
A l’école on m’a appris…                           2
LE CYCLE EN V…      Exigences                                                        Tests fonctionnels               Anal...
ET CA FONCTIONNE ?Bien sûr, si on a des spécificationsimpeccables, limpides et lisibles…                                  ...
ET CA FONCTIONNE ?Par un client qui sait ce qui veut…                                       5
ET CA FONCTIONNE ?Et une équipe de développeurs en bétonqui respectent les délais                                         6
ET DANS LA VRAIE VIE ?Les spécifications arrivent en retard…Sont retouchées…Le développement a été refait 18 fois !Pour te...
DEVELOPMENT HELL               Augmentation               de la pressionBaisse de la                    Moins de temps pou...
EN PLUS… Ce n’est la faute de personneExpression des besoins         Spécifications                Codage               Ca...
EN PLUS… Ce n’est la faute de personneExpression des besoins         Spécifications                                  C’est...
EN PLUS… Ce n’est la faute de personneExpression des besoins                                  C’est mal spécifié !        ...
EN PLUS… Si, c’est celle du client !Expression des besoins                                  C’est mal exprimé !         Sp...
UNE SEULE SOLUTION                 13
Et pourquoi pas autre chose ?                                14
LE DÉVELOPPEMENT PILOTÉ PAR LES TESTS   On écrit les tests AVANT le code   Déroulement :     Ecriture du test     Vérifica...
LE DÉVELOPPEMENT PILOTÉ PAR LES TESTS                           Codage du test       Refactor                             ...
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(qua...
INTÉRÊTLe code produit est testableTest de composants en couche sans avoir besoin descouches de présentationAutomatisation...
Ce n’est pas seulement une        technique…                             19
DANS LES PROJETS INFORMATIQUES…On rencontre principalement 3 typesdintervenants  Ceux qui « spécifient »  Ceux qui « coden...
QUE FAIRE ?Il faut les aider…  à travailler ensemble  à rendre le travail de chacun utile  à se sentir ensemble dans cette...
QUE FAIRE ?Spécifier les comportements avec desexemplesLier les spécifications au code deproductionEcrire des tests avant ...
QUE FAIRE ?Faire des tests les vedettes de votre projetSe mettre daccord sur ce que lon veut puiscoderCapitaliser les conv...
BONNES PRATIQUESTests PetitsTests IsolésFonctionnant sous nimporte quel environnementTests CompletsTests RépétablesTests A...
Et comment faire avec du code        existant ?                                25
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 comme...
ON ÉCRIT LE TEST POUR TOUT LE CODE ? Le projet est gros, il faut donc passer les 6 prochains mois à écrire des tests Evide...
ON COMMENCE PAR 1 TEST !Cherchez une portion de code testable (classe,méthode, fonction…)Ecrivez un test qui porte sur cet...
TESTEZ À CHAQUE MODIFICATION DU CODE    La prochaine fois que vous devez corriger    un bug, écrivez un test qui permet de...
LANCEZ VOS TESTS !Quand vous avez écrit vos tests, vous devezles lancer !Si vous ne le faites pas, ils sont inutiles…Et c’...
LES DÉFAUTS DE L’APPROCHE TDDCoûteux en tempsParfois complexe àconcevoirPeut sembler peu utilecar le développeur doitenvis...
Prochain SlideShare
Chargement dans…5
×

201001 TDD

518 vues

Publié le

by Laurent Caron

Publié dans : Technologie, Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
518
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
19
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

×