Upload
nathaniel-richand
View
3.116
Download
6
Embed Size (px)
DESCRIPTION
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.
Citation preview
Les testsPourquoi? Comment?
Nathaniel Richand
02/2009
© British Telecommunications plc
Sommaire
• Introduction aux tests
• Présentation du Test Driven Development
• Conclusion
• Votre avis
© British Telecommunications plc
Introduction aux tests
© British Telecommunications plc
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
© British Telecommunications plc
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.
© British Telecommunications plc
Pourquoi fait-on si peu de tests?
Pas le temps
Pas un besoin « métier »
Outils pas au point
Seuls les test d’IHM sont plus délicats
Plus les corrections arrivent tard
Plus c’est cher
No comment…
© British Telecommunications plc
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)
© British Telecommunications plc
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
& designDEV
Tests
PROD
Temps
Coût du changement
© British Telecommunications plc
Technical debtNous n’avons pas le
temps de faire des tests ou de refactorer le code
Temps
Cap
acité
à p
rodu
ire
Max
Actuelle
Plus le temps passe, plus Plus le temps passe, plus les erreurs commises se les erreurs commises se
font ressentir.font ressentir.
Code dupliqué
Faiblementtesté
Code dégradé, difficile
Extrait de : Henrik Kniberg – 10 ways to screw up with Scrum and XP
La dette technique fait diminuer La dette technique fait diminuer la productivité au fil du temps.la productivité au fil du temps.
© British Telecommunications plc
Technical debt (2)
Temps
Cap
acité
à p
rodu
ire
TempsC
apac
ité à
pro
duire
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
© British Telecommunications plc
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.
© British Telecommunications plc
LE TDD
© British Telecommunications plc
Test Driven Development?
Ajouter un test
Vérifier que le test échoue
Ecrire le codeVérifier que le
test passe
Refactor
RED
GREEN
REFACTOR
© British Telecommunications plc
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
Philosophie du TDD
Programmation parintention
Notion de design émergent
KISS Keep It Simple, Stupid
© British Telecommunications plc
TDD : Démonstration
Client
Panier
coutTotal : int
ajouterProduit()
enleverProduit()
majCoutTotal()
Produit
nom : String
cout : int
© British Telecommunications plc
Conclusion
© British Telecommunications plc
Comment se lancer
• Java :– Junit !– Dbunit pour les BDD– EasyMock– Unitils
• .Net :– Nunit ou MS Test – Rhino Mocks
• IHM web :– Selenium
© British Telecommunications plc
C’est pas mon boulot?
© British Telecommunications plc
Les problèmes qui surviennent
• Tests trop longs à exécuterUtiliser 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 à testerBesoin bien compris ?Utiliser l’injection de dépendance, des mocks ?
© British Telecommunications plc
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
© British Telecommunications plc
Votre avis?
© British Telecommunications plc
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