Les tests Pourquoi? Comment? Nathaniel Richand 02/2009
Sommaire <ul><li>Introduction aux tests </li></ul><ul><li>Présentation du Test Driven Development </li></ul><ul><li>Conclu...
Introduction aux tests
Il n’y a pas de soucis à livrer du code qui ne fonctionne pas. Quelle est la conséquence ? Enjeux financiers faibles Perte...
De quoi parle-t-on? <ul><li>Différents types de test : </li></ul>IHM Acceptation Intégration Unitaire IHM Acceptation Inté...
Pourquoi fait-on si peu de tests? Seuls les test d’IHM  sont plus délicats Plus les corrections arrivent tard Plus c’est c...
A quoi servent les tests? <ul><li>Assurer la qualité : </li></ul><ul><ul><li>L’application fonctionne </li></ul></ul><ul><...
Manque de temps :  faux problème ? <ul><li>Les bugs doivent être corrigés (en général…) </li></ul><ul><li>  Mieux vaut le ...
Technical debt Nous n’avons pas le temps de faire des tests ou de refactorer le code Temps Capacité à produire Max Actuell...
Technical debt (2) Temps Capacité à produire Temps Capacité à produire Max Actuelle Max Actuelle Produire du code de meill...
Pyramide de Mike Cohn IHM Acceptation Intégration Unitaire Approche traditionelle Approche « agile » Basée sur des cahiers...
LE TDD
Test Driven Development? Ajouter un test Vérifier que le test échoue Ecrire le code Vérifier que le test passe Refactor RE...
Philosophie du TDD On commence par une architecture la plus simple possible, puis on la fait  évoluer  suivant les besoins...
TDD : Démonstration Client Panier coutTotal : int ajouterProduit() enleverProduit() majCoutTotal() Produit nom : String co...
Conclusion
Comment se lancer <ul><li>Java : </li></ul><ul><ul><li>Junit ! </li></ul></ul><ul><ul><li>Dbunit pour les BDD </li></ul></...
C’est pas mon boulot?
Les problèmes qui surviennent <ul><li>Tests trop longs à exécuter </li></ul><ul><ul><li>Utiliser un serveur d’intégration ...
Mon parti pris (qui n’engage que moi) <ul><li>Coder avec des tests est bien plus  agréable  et bien plus  facile . </li></...
Votre avis?
Ressources  <ul><li>Généralité sur les test : </li></ul><ul><li>http://www.testdriven.com </li></ul><ul><li>TDD : </li></u...
Prochain SlideShare
Chargement dans…5
×

Tests Logiciel

4 171 vues

Publié le

Présentation sur les tests logiciels, sur l'intérêt et sur l'approche moderne du tests.
Présentation rapide du TDD et retour d'expérience.

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

Aucun téléchargement
Vues
Nombre de vues
4 171
Sur SlideShare
0
Issues des intégrations
0
Intégrations
106
Actions
Partages
0
Téléchargements
187
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Expliquer pourquoi je fait cette présentation. Pourquoi les tests ont a nouveau la côte. Rapprocher avec les méthodes agiles et XP.
  • Tests Logiciel

    1. 1. Les tests Pourquoi? Comment? Nathaniel Richand 02/2009
    2. 2. Sommaire <ul><li>Introduction aux tests </li></ul><ul><li>Présentation du Test Driven Development </li></ul><ul><li>Conclusion </li></ul><ul><li>Votre avis </li></ul>
    3. 3. Introduction aux tests
    4. 4. Il n’y a pas de soucis à livrer du code qui ne fonctionne pas. Quelle est la conséquence ? Enjeux financiers faibles Perte de confort Enjeux financiers importants Enjeux humains
    5. 5. De quoi parle-t-on? <ul><li>Différents types de test : </li></ul>IHM Acceptation Intégration Unitaire IHM Acceptation Intégration Unitaire Boite blanche Boite noire Tests de l’interface graphique. Identiques à ceux réalisés par la MOA. Tests fonctionnels exécutés avant une livraison (qualification). Valide le fait que toutes les parties développées indépendamment fonctionnent bien ensemble. Teste une partie donnée, indépendamment du reste du programme.
    6. 6. Pourquoi fait-on si peu de tests? Seuls les test d’IHM sont plus délicats Plus les corrections arrivent tard Plus c’est cher No comment… Pas le temps Pas un besoin « métier » Outils pas au point
    7. 7. A quoi servent les tests? <ul><li>Assurer la qualité : </li></ul><ul><ul><li>L’application fonctionne </li></ul></ul><ul><ul><li>L’application fait ce qui est attendu </li></ul></ul><ul><ul><li>L’application a de bonne performance </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>Mais pas que ça : </li></ul><ul><ul><li>Assurer la non régression </li></ul></ul><ul><ul><li>Améliorer la productivité </li></ul></ul><ul><ul><li>Permettre le refactoring </li></ul></ul><ul><ul><li>Permettre de comprendre le code </li></ul></ul><ul><ul><li>(les tests explicitent le code) </li></ul></ul>
    8. 8. Manque de temps : faux problème ? <ul><li>Les bugs doivent être corrigés (en général…) </li></ul><ul><li> Mieux vaut le faire le plus tôt possible. </li></ul>Expression des besoins Analyse & design DEV Tests PROD Temps Coût du changement
    9. 9. Technical debt Nous n’avons pas le temps de faire des tests ou de refactorer le code Temps Capacité à produire Max Actuelle Plus le temps passe, plus les erreurs commises se font ressentir. Code dupliqué Faiblement testé Code dégradé, difficile Extrait de : Henrik Kniberg – 10 ways to screw up with Scrum and XP La dette technique fait diminuer la productivité au fil du temps.
    10. 10. Technical debt (2) Temps Capacité à produire Temps Capacité à produire Max Actuelle Max Actuelle Produire du code de meilleur qualité et testé à un coût plus élevé uniquement sur le court terme . &quot;Ceux qui s'avancent trop précipitamment reculeront encore plus vite.&quot; Meng-Tseu
    11. 11. Pyramide de Mike Cohn IHM Acceptation Intégration Unitaire Approche traditionelle Approche « agile » Basée sur des cahiers de recettes. Coût d’entrée faible. Coût de maintenance très élévé. Basée sur des outils d’automatisation. Coût d’entrée plus élevé. Coût de maintenance assez faible.
    12. 12. LE TDD
    13. 13. Test Driven Development? Ajouter un test Vérifier que le test échoue Ecrire le code Vérifier que le test passe Refactor RED GREEN REFACTOR
    14. 14. Philosophie du TDD On commence par une architecture la plus simple possible, puis on la fait évoluer suivant les besoins. On ne code que ce qui correspond à un besoin bien identifié, que l’on sait tester Programmation par intention Notion de design émergent KISS Keep It Simple, Stupid
    15. 15. TDD : Démonstration Client Panier coutTotal : int ajouterProduit() enleverProduit() majCoutTotal() Produit nom : String cout : int
    16. 16. Conclusion
    17. 17. Comment se lancer <ul><li>Java : </li></ul><ul><ul><li>Junit ! </li></ul></ul><ul><ul><li>Dbunit pour les BDD </li></ul></ul><ul><ul><li>EasyMock </li></ul></ul><ul><ul><li>Unitils </li></ul></ul><ul><li>.Net : </li></ul><ul><ul><li>Nunit ou MS Test </li></ul></ul><ul><ul><li>Rhino Mocks </li></ul></ul><ul><li>IHM web : </li></ul><ul><ul><li>Selenium </li></ul></ul>
    18. 18. C’est pas mon boulot?
    19. 19. Les problèmes qui surviennent <ul><li>Tests trop longs à exécuter </li></ul><ul><ul><li>Utiliser un serveur d’intégration continu </li></ul></ul><ul><li>Maintenabilité des tests </li></ul><ul><ul><li>Les tests doivent évoluer en parallèle du code </li></ul></ul><ul><ul><li>Ne pas faire de tests inutiles </li></ul></ul><ul><li>Manque d’engagement de l’équipe </li></ul><ul><ul><li>Si l’équipe ne vérifie pas le passage des tests, ne fait pas évoluer les tests, alors l’intérêt est faible… </li></ul></ul><ul><li>Code trop difficile à tester </li></ul><ul><ul><li>Besoin bien compris ? </li></ul></ul><ul><ul><li>Utiliser l’injection de dépendance, des mocks ? </li></ul></ul>
    20. 20. Mon parti pris (qui n’engage que moi) <ul><li>Coder avec des tests est bien plus agréable et bien plus facile . </li></ul><ul><li>Ne pas faire trop de tests non plus. </li></ul><ul><ul><li>Se concentrer sur les parties «métier» en unitaire </li></ul></ul><ul><ul><li>Faire des tests fonctionnels de l’application. </li></ul></ul><ul><li>Avec habitude les tests deviennent très rapide à produire . </li></ul><ul><li>Je fais beaucoup moins de bugs (j’ai l’impression!). </li></ul>Dépend du contexte
    21. 21. Votre avis?
    22. 22. Ressources <ul><li>Généralité sur les test : </li></ul><ul><li>http://www.testdriven.com </li></ul><ul><li>TDD : </li></ul><ul><li>Test Driven: TDD and Acceptance TDD for Java Developers - Lasse Koskela </li></ul><ul><li>Guides de bonnes pratiques de tests en java : </li></ul><ul><li>http://unitils.org/guidelines.html </li></ul><ul><li>Outils .net : </li></ul><ul><li>http://www.artofunittesting.com/Chapters/Tools_and_frameworks </li></ul>

    ×