Téléchargé 92 fois
Téléchargé parJérôme Avoustin
Le pilotage par les tests
Le document présente un retour d'expérience sur le pilotage des tests dans un projet de développement, mettant en avant les approches TDD, ATDD et BDD. Il aborde l'importance de la qualité dans le code, le coût d'ajout de fonctionnalités, et les stratégies de test adoptées par l'équipe. Enfin, des conseils pratiques sont donnés pour réussir le TDD et le BDD, tout en soulignant l'importance de la culture de test dans le développement logiciel.
![eXtreme Programming [fr]](https://cdn.slidesharecdn.com/ss_thumbnails/xp-100209112128-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![Importancia de un plan de negocio[1]](https://cdn.slidesharecdn.com/ss_thumbnails/importanciadeunplandenegocio1-111013222023-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Agile Testing Day] Introduction](https://cdn.slidesharecdn.com/ss_thumbnails/intro-michelperfetti-160126175852-thumbnail.jpg?width=640&height=640&fit=bounds)
Le pilotage par les tests
- 1. Le pilotage parles tests Mise en pratique et retour d’expérience
- 2. Merci à nossponsors !
- 3. Moi… Jérôme Avoustin .NET, Agilité, Performance @JeromeAvoustin http://blog.avoustin.com Agilité, AMOA, .NET, SharePoint http://www.smartview.fr
- 4. De quoi va-t-onparler ? Given Emergent Design Business A Cucumber Needs Qualité TBDDTests xBehave Unit Red TDDxUnit d’acceptance D Green D Refactoring Tests When Then Spec
- 5. De quoi va-t-onparler ? Given Emergent Design Business A Cucumber Needs Qualité TBDDTests xBehave Unit Red TDDxUnit d’acceptance D Green D Refactoring Tests When Then Spec
- 6. C’est quoi la Qualité ?
- 7.
- 8. Sur twitter Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler Codez toujours en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse. Martin Golding My project is 90% done. I hope the second half goes as well. Scott W. Ambler J’écris des tests qui passent avant d’avoir écrit le code. Chuck Norris
- 9. Sur Wikipedia Aptitude d’unensemble de caractéristiques intrinsèques à satisfaire les besoins exprimés ou potentiels des utilisateurs. Niveau de finition ou de perfection d’exécution d’une action ou d’un produit.
- 10. Une autre proposition… Uneapplication informatique est de qualité lorsque le coût d’ajout d’une fonctionnalité est stable.
- 11. Une autre proposition… Une application informatique est de qualité lorsque le coût d’ajout d’une fonctionnalité est stable. Coût Temps
- 12. Les types dedette Code Tests Obsolescence Besoins
- 13. Pourquoi automatiser letest ?
- 14. Les stratégies detest Pas de tests Test-after Test-first TDD
- 15. Un peu dephilo Validation du code T est Centré sur le besoin D riven Design émergent D evelopment esign Refactoring intensif
- 16. Concrètement, c’est quoile TDD ? 1. Red 2. Green 3. Refactor
- 17.
- 18. Et l’ATDD ? Intégrer le client Réduire dans le processus l’interprétabilité Acceptance Améliore le TDD Spécification feedback par l’exemple Spécifications exécutables
- 19. Position dans leprocessus Vision
- 20.
- 21. Quid du BDD? Test Comportement Test = documentation Behaviour DD Comportement DevraitFaire… décrit dans le ou nom de la méthode NeDevraitPasFaire…
- 22. Quid du BDD? 1 Comportement = 1 critère d’acceptance Plus de proximité avec le client Behaviour Langage DD universel Given <contexte> When <action> Then <résultat> 1 DSL : le Gherkin
- 23.
- 24. Quand s’en servir? Types de tests TDD ATDD BDD Tests unitaires Tests d’intégration Tests fonctionnels Tests d’interface Tests d’ergonomie Tests de performance
- 25. En résumé Developer Customer centric centric TDD ATDD BDD
- 26. Retour d’expérience :Le contexte • Domaine de l’assurance • Développement d’un extranet • Application Web traditionnelle o MVC o Repository + NHibernate • Equipe assez hétérogène o Histoire, expériences, âges, compétences • Pas d’habitude des tests automatisés • Adhésion du management aux pratiques agiles
- 27. Approche des testsen Top Down Tests d’interfaces Red BDD Green Tests unitaires des Controller SpecFlow Red Green (Cucumber-like) + WatiN + NUnit Tests unitaires des Repository Refactor NUnit Red Green Refactor NUnit
- 28. Un petit bilan… Pas simple tous les jours… Plein de questions… 83% …de couverture ! Un surcoût…! Un code assez clean !
- 29. Les tests OK,mais pour quel coût ? 100% 120%
- 30. Où est l’intérêtfinalement ? • Le temps de Debug, passe sur le temps de Tests • Le temps de Tests prend en compte : o Une partie de la rédaction de specs, o La réalisation de tests manuels de non régression • La recette existe toujours ! • Le temps de Dev prend en compte le refactoring • On a réduit drastiquement le nombre de bugs • On n’écrit plus de code inutile • On a gagné en prédictibilité ! o Le temps de Debug est imprévisible
- 31. Les questions quise sont posées... Par où commencer ? Par le test le plus simple ! Par quoi poursuivre ? Par le prochain test le plus simple ! Faut-il tester les méthodes « passe-plats » ? A vous de voir… Jusqu’où s’arrêter ? Faut-il TOUT tester ? J’y répondrai à la fin…
- 32. …et qui seposent encore ! Faut-il des mocks ou des stubs ? De manière générale, des stubs, mais les mocks ont leur utilité http://martinfowler.com/articles/mocksArentStubs.html Le critère d’acceptance du PO est nul ! Mettons-nous autour de la table…
- 33. Quelques conseils sur…le TDD • Pour être testée, une application doit être… testable ! o Privilégier l’injection de dépendance o Privilégier les frameworks « testables » unitairement o Eliminer tout ce qui est static • Ne passez pas trop de temps sur un test • 1 chose testée par méthode de test o Plusieurs Assert permis… • Ne courrez pas derrière le 100% de couverture • Ajouter un test lorsque vous rencontrez un bug
- 34. Quelques conseils surle… BDD • Utilisez le plus haut niveau d’abstraction métier possible dans vos descriptions o Exemple : Given je suis sur la page d’accueil et non Given je vais à l’URL http://localhost:87675/ • Concentrez le test sur ce qui doit être testé o Ne pas répéter des étapes o Dans le Given, décrire le contexte le plus tard possible
- 35. Quelques conseils surle… Refactoring • Ne reportez pas le Refactoring à plus tard o Dette technique ! • Commencez par refactorer les tests !!!! • Mettez en place la règle du Boy Scout o « A chaque fois que je passe à un endroit, je le rends un tout petit peu plus propre qu’il ne l’était avant » • Inspirez-vous du Software Craftsmanship
- 36. Récapitulons… Spécification Design Interaction Le pilotage par les tests Formalisme 1 Process Qualité
- 37. C’est surtout unétat d’esprit ! Attention au changement de culture ! Osez vous tromper !... …Et persévérez ! Soyez curieux, et regardez toutes les pratiques (Faites des dojos !) Faites appel à votre bon sens !!
- 38. Pour aller plusloin http://dannorth.net/introducing-bdd/ @kentbeck @jamesshore http://www.ibm.com/developerworks/java/libr @gojkoadzic ary/j-eaed2/index.html @martinfowler @tastapod @ericminio
- 39. Merci ! Desquestions ? Jérôme Avoustin @JeromeAvoustin jerome.avoustin@smartview.fr http://www.smartview.fr http://blog.avoustin.com Scrum Pastis Montpellier : 22/11/2011 Meetup : http://past.is/bP2R Questionnaire : http://past.is/bPza
Notes de l'éditeur
- #15 PAS DE TESTS : cas des forfaits. Dette technique et dette de tests énormes. Heures de séance de débuggage assurées. Cas : pas le temps OU pas besoin car trop fortsTEST AFTER : intérêt des tests limité. On ne fait du test que pour le test. Mais c’est trop tard ! On ne teste que les cas les plus évidents. Sous le stress du résultat, on abandonne. Le test est souvent mal écrit, peu efficace et peu maintenable.TEST FIRST : Le test sans le refactoring
- #22 Nom de la méthode important pour : bien comprendre le comportement ciblé, savoir exactement ce qu’il ne va pas en cas d’échec[Reprendre exemple TDD]