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.
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.
8.
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