Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare une entreprise Scribd logo

Tests Logiciel

•Télécharger en tant que PPT, PDF•
•

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.

1  sur  22
Les tests Pourquoi? Comment? Nathaniel Richand 02/2009
Sommaire Introduction aux tests Présentation du Test Driven Development Conclusion Votre avis
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 confort Enjeux financiers importants Enjeux humains
De quoi parle-t-on? Différents types de test : 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.
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
A quoi servent les tests? Assurer la qualité : L’application fonctionne L’application fait ce qui est attendu L’application a de bonne performance … Mais pas que ça : Assurer la non régression Améliorer la productivité Permettre le refactoring Permettre de comprendre le code (les tests explicitent le code)
Manque de temps : faux problème ? Les bugs doivent être corrigés (en général…) Mieux vaut le faire le plus tôt possible. Expression des besoins Analyse & design DEV Tests PROD Temps Coût du changement
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.
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 . "Ceux qui s'avancent trop précipitamment reculeront encore plus vite." Meng-Tseu
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.
LE TDD
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
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
TDD : Démonstration Client Panier coutTotal : int ajouterProduit() enleverProduit() majCoutTotal() Produit nom : String cout : int
Conclusion
Comment se lancer Java : Junit ! Dbunit pour les BDD EasyMock Unitils .Net : Nunit ou MS Test Rhino Mocks IHM web : Selenium
C’est pas mon boulot?
Les problèmes qui surviennent Tests trop longs à exécuter Utiliser un serveur d’intégration continu Maintenabilité des tests Les tests doivent évoluer en parallèle du code Ne pas faire de tests inutiles Manque d’engagement de l’équipe Si l’équipe ne vérifie pas le passage des tests, ne fait pas évoluer les tests, alors l’intérêt est faible… Code trop difficile à tester Besoin bien compris ? Utiliser l’injection de dépendance, des mocks ?
Mon parti pris (qui n’engage que moi) Coder avec des tests est bien plus agréable et bien plus facile . Ne pas faire trop de tests non plus. Se concentrer sur les parties «métier» en unitaire Faire des tests fonctionnels de l’application. Avec habitude les tests deviennent très rapide à produire . Je fais beaucoup moins de bugs (j’ai l’impression!). Dépend du contexte
Votre avis?
Ressources Généralité sur les test : http://www.testdriven.com TDD : Test Driven: TDD and Acceptance TDD for Java Developers - Lasse Koskela Guides de bonnes pratiques de tests en java : http://unitils.org/guidelines.html Outils .net : http://www.artofunittesting.com/Chapters/Tools_and_frameworks

Contenu connexe

Tests Logiciel

  • 1. Les tests Pourquoi? Comment? Nathaniel Richand 02/2009
  • 2. Sommaire Introduction aux tests Présentation du Test Driven Development Conclusion Votre avis
  • 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. De quoi parle-t-on? Différents types de test : 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. 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. A quoi servent les tests? Assurer la qualité : L’application fonctionne L’application fait ce qui est attendu L’application a de bonne performance … Mais pas que ça : Assurer la non régression Améliorer la productivité Permettre le refactoring Permettre de comprendre le code (les tests explicitent le code)
  • 8. Manque de temps : faux problème ? Les bugs doivent être corrigés (en général…) Mieux vaut le faire le plus tôt possible. Expression des besoins Analyse & design DEV Tests PROD Temps Coût du changement
  • 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. 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 . "Ceux qui s'avancent trop précipitamment reculeront encore plus vite." Meng-Tseu
  • 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.
  • 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. 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. TDD : Démonstration Client Panier coutTotal : int ajouterProduit() enleverProduit() majCoutTotal() Produit nom : String cout : int
  • 17. Comment se lancer Java : Junit ! Dbunit pour les BDD EasyMock Unitils .Net : Nunit ou MS Test Rhino Mocks IHM web : Selenium
  • 18. C’est pas mon boulot?
  • 19. Les problèmes qui surviennent Tests trop longs à exécuter Utiliser un serveur d’intégration continu Maintenabilité des tests Les tests doivent évoluer en parallèle du code Ne pas faire de tests inutiles Manque d’engagement de l’équipe Si l’équipe ne vérifie pas le passage des tests, ne fait pas évoluer les tests, alors l’intérêt est faible… Code trop difficile à tester Besoin bien compris ? Utiliser l’injection de dépendance, des mocks ?
  • 20. Mon parti pris (qui n’engage que moi) Coder avec des tests est bien plus agréable et bien plus facile . Ne pas faire trop de tests non plus. Se concentrer sur les parties «métier» en unitaire Faire des tests fonctionnels de l’application. Avec habitude les tests deviennent très rapide à produire . Je fais beaucoup moins de bugs (j’ai l’impression!). Dépend du contexte
  • 22. Ressources Généralité sur les test : http://www.testdriven.com TDD : Test Driven: TDD and Acceptance TDD for Java Developers - Lasse Koskela Guides de bonnes pratiques de tests en java : http://unitils.org/guidelines.html Outils .net : http://www.artofunittesting.com/Chapters/Tools_and_frameworks

Notes de l'éditeur

  1. Expliquer pourquoi je fait cette présentation. Pourquoi les tests ont a nouveau la côte. Rapprocher avec les méthodes agiles et XP.