Le document présente l'importance des tests dans le développement logiciel, notamment à travers le Test Driven Development (TDD) qui favorise la qualité du code et la compréhension des exigences. Il aborde les types de tests, les enjeux liés à leur mise en œuvre, et comment la dette technique impacte la productivité. Enfin, il recommande des outils pour faciliter le processus de test et encourage une culture d'équipe engagée dans la vérification régulière des tests.

1. Les tests Pourquoi? Comment? Nathaniel Richand 02/2009

2. Sommaire Introduction aux tests Présentation du Test Driven Development Conclusion Votre avis

3. Introduction aux tests

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.

12. LE TDD

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

16. Conclusion

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

21. Votre avis?

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