SlideShare une entreprise Scribd logo
1  sur  20
Télécharger pour lire hors ligne
05/05/2015
06/05/2015
Introduction au Test-Driven Development
Agenda
1. Problématique
2. Présentation du TDD
3. Le TDD en pratique
4. Références
05/05/2015
Problématique
05/05/2015
Le paradoxe
05/05/2015
“We launch a 2014 product with a 1970’s
software process using management
techniques from the 1920’s.”
- @davidjbland
Et c’est le drame
05/05/2015
Et les commentaires ?
05/05/2015
Présentation du TDD
05/05/2015
Principe
05/05/2015
Implications
• Test = traduction des demandes métier dans le
code
• Validation du fonctionnement
• Ceinture de sécurité pour le refactoring
• 0 régression
• Design émergent
• On livre quand on veut
05/05/2015
Attention…
05/05/2015
Tests End-
to-end
Tests
d’intégration
Tests unitaires
TDD
Le TDD en pratique
05/05/2015
Besoin d’une approche structurée
• Interactions avec le métier :
– Définitions des besoins pour savoir quoi tester
– Feedbacks réguliers
– Savoir communiquer !
• Savoir découper les tâches finement
• Principes SOLID
• Intégration continue
05/05/2015
Faites comme lui
05/05/2015
Difficultés
• Pas intuitif
• Résister à l’envie de coder “trop” : baby steps,
KISS
• Besoin du soutien du métier et du
management
05/05/2015
N’oubliez pas…
05/05/2015
Concrètement
• Frameworks : test, mock, DI
• Outils : coverage, assistance
• Katas
– Pour comprendre
– Pour s’habituer
– Pour s’améliorer
05/05/2015
Pour conclure
C’est VOTRE carrière qui est en jeu
05/05/2015
Références
05/05/2015
Références
• http://en.wikipedia.org/wiki/Test-driven_development
• Un livre : Professional Test-Driven Development with C#
• http://fr.slideshare.net/brunoboucard/si-le-tdd-est-
mort-alors-mix-it Présentation de TDD par B. Boucard
et T. Pierrain (SGCIB) au dernier Mix-IT de Lyon
• http://googletesting.blogspot.co.uk/2015/04/just-say-
no-to-more-end-to-end-tests.html
• http://www.codewars.com pour trouver des exercices
• http://www.osherove.com en particulier la section Kata
• http://www.jbrains.ca/permalink/tdd-is-not-magic
05/05/2015
Merci !
Rendez-vous d’ici fin mai pour
pratiquer en .Net !
@GTechene
guillaume.techene@nexeo.fr
http://guillaume.techene.net/blog/
05/05/2015

Contenu connexe

En vedette

Lumiere tdd agilefrance2013
Lumiere tdd agilefrance2013Lumiere tdd agilefrance2013
Lumiere tdd agilefrance2013Eric Le Merdy
 
Teaching TDD, the Coding Dojo Style
Teaching TDD, the Coding Dojo StyleTeaching TDD, the Coding Dojo Style
Teaching TDD, the Coding Dojo StyleRamiro Luz
 
TDD - Test Driven Dvelopment | Test First Design
TDD -  Test Driven Dvelopment | Test First DesignTDD -  Test Driven Dvelopment | Test First Design
TDD - Test Driven Dvelopment | Test First DesignQuang Nguyễn Bá
 
Coding Dojo Introduction
Coding Dojo IntroductionCoding Dojo Introduction
Coding Dojo IntroductionDanilo Sato
 
Si le tdd est mort alors pratiquons une autopsie mix-it 2015
Si le tdd est mort alors pratiquons une autopsie mix-it 2015Si le tdd est mort alors pratiquons une autopsie mix-it 2015
Si le tdd est mort alors pratiquons une autopsie mix-it 2015Bruno Boucard
 
Démons en PHP, de inetd à ZeroMQ
Démons en PHP, de inetd à ZeroMQDémons en PHP, de inetd à ZeroMQ
Démons en PHP, de inetd à ZeroMQAmaury Bouchard
 
Apache Kafka, Un système distribué de messagerie hautement performant
Apache Kafka, Un système distribué de messagerie hautement performantApache Kafka, Un système distribué de messagerie hautement performant
Apache Kafka, Un système distribué de messagerie hautement performantALTIC Altic
 
Apache Kafka 0.8 basic training - Verisign
Apache Kafka 0.8 basic training - VerisignApache Kafka 0.8 basic training - Verisign
Apache Kafka 0.8 basic training - VerisignMichael Noll
 

En vedette (12)

Lumiere tdd agilefrance2013
Lumiere tdd agilefrance2013Lumiere tdd agilefrance2013
Lumiere tdd agilefrance2013
 
Coding Dojo In 5 minutes
Coding Dojo In 5 minutesCoding Dojo In 5 minutes
Coding Dojo In 5 minutes
 
Teaching TDD, the Coding Dojo Style
Teaching TDD, the Coding Dojo StyleTeaching TDD, the Coding Dojo Style
Teaching TDD, the Coding Dojo Style
 
TDD - Test Driven Dvelopment | Test First Design
TDD -  Test Driven Dvelopment | Test First DesignTDD -  Test Driven Dvelopment | Test First Design
TDD - Test Driven Dvelopment | Test First Design
 
Coding Dojo
Coding DojoCoding Dojo
Coding Dojo
 
Coding Dojo
Coding DojoCoding Dojo
Coding Dojo
 
Et si on jouait au tdd 20131017
Et si on jouait au tdd 20131017Et si on jouait au tdd 20131017
Et si on jouait au tdd 20131017
 
Coding Dojo Introduction
Coding Dojo IntroductionCoding Dojo Introduction
Coding Dojo Introduction
 
Si le tdd est mort alors pratiquons une autopsie mix-it 2015
Si le tdd est mort alors pratiquons une autopsie mix-it 2015Si le tdd est mort alors pratiquons une autopsie mix-it 2015
Si le tdd est mort alors pratiquons une autopsie mix-it 2015
 
Démons en PHP, de inetd à ZeroMQ
Démons en PHP, de inetd à ZeroMQDémons en PHP, de inetd à ZeroMQ
Démons en PHP, de inetd à ZeroMQ
 
Apache Kafka, Un système distribué de messagerie hautement performant
Apache Kafka, Un système distribué de messagerie hautement performantApache Kafka, Un système distribué de messagerie hautement performant
Apache Kafka, Un système distribué de messagerie hautement performant
 
Apache Kafka 0.8 basic training - Verisign
Apache Kafka 0.8 basic training - VerisignApache Kafka 0.8 basic training - Verisign
Apache Kafka 0.8 basic training - Verisign
 

Similaire à Atelier tdd v1.4

Petit Déjeuner TDR
Petit Déjeuner TDRPetit Déjeuner TDR
Petit Déjeuner TDRguest4e4aad
 
Altran soirée du test logiciel - assez des c 05-10-17
Altran   soirée du test logiciel - assez des c 05-10-17Altran   soirée du test logiciel - assez des c 05-10-17
Altran soirée du test logiciel - assez des c 05-10-17Marc Hage Chahine
 
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...TelecomValley
 
Human Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDDHuman Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDDXavier NOPRE
 
Microsoft DevOps Day 2015 02122015 - L'expérience du groupe produit Visual St...
Microsoft DevOps Day 2015 02122015 - L'expérience du groupe produit Visual St...Microsoft DevOps Day 2015 02122015 - L'expérience du groupe produit Visual St...
Microsoft DevOps Day 2015 02122015 - L'expérience du groupe produit Visual St...Samuel Metias
 
L'agilité chez Jouve via le Behaviour Driven Development
L'agilité chez Jouve via le Behaviour Driven DevelopmentL'agilité chez Jouve via le Behaviour Driven Development
L'agilité chez Jouve via le Behaviour Driven DevelopmentJouve
 
20141113 devoxx2014 jochim van dorpe testing in agile
20141113 devoxx2014 jochim van dorpe testing in agile20141113 devoxx2014 jochim van dorpe testing in agile
20141113 devoxx2014 jochim van dorpe testing in agileSmals
 
Think tank présentation
Think tank   présentationThink tank   présentation
Think tank présentationJacky Galicher
 
Introduction aux principes du Responsive Web Design
 Introduction aux principes du Responsive Web Design Introduction aux principes du Responsive Web Design
Introduction aux principes du Responsive Web DesignStrasWeb
 
2015-04-28 Bruno Guay Sécurité des projets informatiques
2015-04-28 Bruno Guay Sécurité des projets informatiques2015-04-28 Bruno Guay Sécurité des projets informatiques
2015-04-28 Bruno Guay Sécurité des projets informatiquesPMI Lévis-Québec
 
Agilité, Tests Et Industrialisation
Agilité, Tests Et IndustrialisationAgilité, Tests Et Industrialisation
Agilité, Tests Et IndustrialisationPHPPRO
 
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile? Et saura-t-elle f...
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile?  Et saura-t-elle f...ATMTL23 - La QA a-t-elle reussi à prendre le virage agile?  Et saura-t-elle f...
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile? Et saura-t-elle f...Agile Montréal
 
NDepend 5 en action par son créateur
NDepend 5 en action par son créateurNDepend 5 en action par son créateur
NDepend 5 en action par son créateurMicrosoft
 
BAFS 2015 Paris : Olivier Durant - Business Analyst et Business Architecte - ...
BAFS 2015 Paris : Olivier Durant - Business Analyst et Business Architecte - ...BAFS 2015 Paris : Olivier Durant - Business Analyst et Business Architecte - ...
BAFS 2015 Paris : Olivier Durant - Business Analyst et Business Architecte - ...BAFS
 
BAFS 2015 Paris : Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
BAFS 2015 Paris : Atelier BPMS - Une démarche outillée de BA : Adequate Solut...BAFS 2015 Paris : Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
BAFS 2015 Paris : Atelier BPMS - Une démarche outillée de BA : Adequate Solut...BAFS
 
Service Desk à DevOps
Service Desk à DevOps Service Desk à DevOps
Service Desk à DevOps Jacky Galicher
 
BAFS 2015 Genève: Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
BAFS 2015 Genève: Atelier BPMS - Une démarche outillée de BA : Adequate Solut...BAFS 2015 Genève: Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
BAFS 2015 Genève: Atelier BPMS - Une démarche outillée de BA : Adequate Solut...BAFS
 
Agile Tour 2012 Paris - Nouveaux Outils Agile MS
Agile Tour 2012 Paris - Nouveaux Outils Agile MS Agile Tour 2012 Paris - Nouveaux Outils Agile MS
Agile Tour 2012 Paris - Nouveaux Outils Agile MS Cédric Leblond
 

Similaire à Atelier tdd v1.4 (20)

Petit Déjeuner TDR
Petit Déjeuner TDRPetit Déjeuner TDR
Petit Déjeuner TDR
 
Altran soirée du test logiciel - assez des c 05-10-17
Altran   soirée du test logiciel - assez des c 05-10-17Altran   soirée du test logiciel - assez des c 05-10-17
Altran soirée du test logiciel - assez des c 05-10-17
 
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
 
Human Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDDHuman Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDD
 
20111004 04 - Présentation ATDD
20111004 04 - Présentation ATDD20111004 04 - Présentation ATDD
20111004 04 - Présentation ATDD
 
Microsoft DevOps Day 2015 02122015 - L'expérience du groupe produit Visual St...
Microsoft DevOps Day 2015 02122015 - L'expérience du groupe produit Visual St...Microsoft DevOps Day 2015 02122015 - L'expérience du groupe produit Visual St...
Microsoft DevOps Day 2015 02122015 - L'expérience du groupe produit Visual St...
 
L'agilité chez Jouve via le Behaviour Driven Development
L'agilité chez Jouve via le Behaviour Driven DevelopmentL'agilité chez Jouve via le Behaviour Driven Development
L'agilité chez Jouve via le Behaviour Driven Development
 
20141113 devoxx2014 jochim van dorpe testing in agile
20141113 devoxx2014 jochim van dorpe testing in agile20141113 devoxx2014 jochim van dorpe testing in agile
20141113 devoxx2014 jochim van dorpe testing in agile
 
Think tank présentation
Think tank   présentationThink tank   présentation
Think tank présentation
 
Introduction aux principes du Responsive Web Design
 Introduction aux principes du Responsive Web Design Introduction aux principes du Responsive Web Design
Introduction aux principes du Responsive Web Design
 
2015-04-28 Bruno Guay Sécurité des projets informatiques
2015-04-28 Bruno Guay Sécurité des projets informatiques2015-04-28 Bruno Guay Sécurité des projets informatiques
2015-04-28 Bruno Guay Sécurité des projets informatiques
 
Agilité, Tests Et Industrialisation
Agilité, Tests Et IndustrialisationAgilité, Tests Et Industrialisation
Agilité, Tests Et Industrialisation
 
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile? Et saura-t-elle f...
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile?  Et saura-t-elle f...ATMTL23 - La QA a-t-elle reussi à prendre le virage agile?  Et saura-t-elle f...
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile? Et saura-t-elle f...
 
Cycle de développement pour les TPO (Norme ISO/IEC 29110)
Cycle de développement pour les TPO (Norme ISO/IEC 29110) Cycle de développement pour les TPO (Norme ISO/IEC 29110)
Cycle de développement pour les TPO (Norme ISO/IEC 29110)
 
NDepend 5 en action par son créateur
NDepend 5 en action par son créateurNDepend 5 en action par son créateur
NDepend 5 en action par son créateur
 
BAFS 2015 Paris : Olivier Durant - Business Analyst et Business Architecte - ...
BAFS 2015 Paris : Olivier Durant - Business Analyst et Business Architecte - ...BAFS 2015 Paris : Olivier Durant - Business Analyst et Business Architecte - ...
BAFS 2015 Paris : Olivier Durant - Business Analyst et Business Architecte - ...
 
BAFS 2015 Paris : Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
BAFS 2015 Paris : Atelier BPMS - Une démarche outillée de BA : Adequate Solut...BAFS 2015 Paris : Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
BAFS 2015 Paris : Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
 
Service Desk à DevOps
Service Desk à DevOps Service Desk à DevOps
Service Desk à DevOps
 
BAFS 2015 Genève: Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
BAFS 2015 Genève: Atelier BPMS - Une démarche outillée de BA : Adequate Solut...BAFS 2015 Genève: Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
BAFS 2015 Genève: Atelier BPMS - Une démarche outillée de BA : Adequate Solut...
 
Agile Tour 2012 Paris - Nouveaux Outils Agile MS
Agile Tour 2012 Paris - Nouveaux Outils Agile MS Agile Tour 2012 Paris - Nouveaux Outils Agile MS
Agile Tour 2012 Paris - Nouveaux Outils Agile MS
 

Atelier tdd v1.4

Notes de l'éditeur

  1. On veut un produit moderne qui réponde aux besoins actuels mais on utilise un process waterfall datant de la fin des années 60 en utilisant un modèle de management qui n’est pas adapté. Le métier effectue beaucoup de demandes souvent mal priorisées, avec parfois un besoin mal défini. Il met alors de la pression pour voir le livrable ASAP ; or, la gestion actuelle des projets fait que les livrables n’arrivent qu’à la toute fin voire après la deadline. Les tests, vus comme optionnels car n’apportant pas de plus-value au métier, sont décalés à la fin voire jamais faits du tout.
  2. Les utilisateurs n’ayant pas été mis dans la boucle durant le process découvrent l’appli une fois “finie”. Ils font souvent des retours violents, comme telle ou telle fonctionnalité importante qui manque ou qui ne marche pas du tout comme elle devrait. Du coup le dev se met à corriger en urgence et introduit des régressions et des bugs récurrents. L’absence de tests commence à se faire sentir. L’architecture devient de plus en plus alambiquée et difficile à comprendre, ce qui favorise les nouvelles régressions. Il est alors de plus en plus difficile de toucher au code sans casser quoi que ce soit à côté mais un refactoring est hors de question puisqu’il faudrait demander aux utilisateurs et BA de retester toute l’appli depuis le début pour vérifier les TNR blocage au niveau du budget qui crève le plafond. En plus, la doc et les specs écrites au début (“quand on avait le temps”) ne correspondent plus à l’état du code.  Le code est monolithique, l’application bancale, les coûts sont monstrueux, tout le monde est mécontent.
  3. Les commentaires sont trop souvent obsolètes. Au mieux ils ne servent à rien, au pire ils vont induire en erreur. Les rares commentaires utiles décrivent des comportements métier très pointus et difficiles à comprendre pour un non-initié (ex : grosse formule de maths). Mais le risque lié à l’obsolescence subsiste.
  4. Au début d’un développement, on commence par coder les tests unitaires. Pas de code avant, le test doit planter. “Red, Green, Refactor” : Red : Le test plante. Green : On écrit juste le code nécessaire au passage du test, ce qui évite d’introduire du code inutile et un design potentiellement lourd. Refactor : On met le code au propre (si nécessaire). Une fois la feature finie, on commite. On peut même commiter une fois que le test passe. Et on recommence.
  5. Le fait d’écrire les tests permet de traduire le besoin métier en code ; on s’assure donc dès le départ de bien comprendre les specs. On a des tests qui valident un fonctionnement  on peut donc refactorer le code testé quand on veut sans craindre les régressions à gogo. Le design de l’application se fait petit à petit, on part d’une base simple pour évoluer ensuite. On pourra en effet refactorer facilement, donc l’archi peut évoluer sans crainte. C’est un point majeur, car on évite de stagner dans une archi inadéquate, souvent source de bien des maux (contournements, régressions, etc…). Lorsqu’on a un bug, soit un ou des tests plantent et on peut cibler facilement ce qui ne va pas, soit on n’a qu’à ajouter le cas de test ensuite pour prévenir le bug de resurgir ensuite. On peut livrer au métier quand on veut puisque les tests passent. Cela ne signifie pas que l’appli est finie mais qu’une partie est livrable et testable en l’état. On peut donc mettre le métier dans la boucle plus vite et avoir des feedbacks plus rapprochés. L’itération et l’incrémentation sont au coeur du process : on est “Agile”.
  6. Le TDD concerne essentiellement les tests unitaires. Il faut bien faire attention à rester très précis et bien cibler ce que l’on teste. Un test d’intégration n’a pas lieu d’être à ce stade, car il couvre trop de périmètre et ne permet pas l’approche itérative citée précédemment, sans parler du temps et des ressources nécessaires au lancement de ce type de test. Le test unitaire a un but technique, il ne servira que peu aux BA ou utilisateurs. Contrairement au test d’intégration ou au test end-to-end qui valideront eux un véritable comportement métier.
  7. Les interactions avec le métier sont fréquentes : il est donc impératif 1) de savoir communiquer et 2) que le métier soit OK avec ça ! Si le métier ne veut pas fonctionner dans ce mode, soit il faut avoir de bons BA, soit le projet est compromis. Pour des tests unitaires, on veut une granularité très fine. Il est donc indispensable de découper chaque demande métier en plusieurs tâches, elles-mêmes divisées en plusieurs parties. Chaque partie fera l’objet de plusieurs tests visant à vérifier le comportement pour plusieurs données en entrée. Afin de bien développer l’application et de la rendre testable, on a besoin de s’appuyer sur les principes SOLID, notamment S et D. Voir http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 Evidemment, créer une batterie de tests unitaires n’est utile que si ces tests sont rejoués régulièrement… d’où le besoin d’un environnement d’intégration continue avec usine de build et lancement automatique des tests.
  8. On procède petit à petit ! Notion de “baby steps”. Un bon test unitaire : Ne teste qu’une seule chose à la fois : une seule classe, une seule méthode Isole le code de l’environnement et du contexte, quitte à fournir des implémentations tronquées ou bidon des dépendances (“mocking”). Sinon on tombe dans le test d’intégration et on est hors scope. S’exécute rapidement car il est lancé souvent. Teste aussi les cas à la marge pour éviter de ne tester que le “happy path” qui est le cas idéal où tout se déroule parfaitement. Si une méthode prend une chaîne en paramètre, il faut aussi penser à tester le cas où la chaîne est null ou vide.
  9. Il est difficile de commencer par coder un test qui va appeler du code qui n’existe pas encore. Ce n’est pas naturel… et c’est normal ! Mais l’habitude vient vite, il suffit de pratiquer. Du coup, quand on code, on a souvent envie d’aller plus loin que de répondre simplement au test. Oui mais cela signifie qu’on implémente un besoin pas demandé par le métier ou qu’on est en train de complexifier l’architecture pour rien… Il faut savoir résister à cette envie et faire simplement ce qui a été demandé. KISS : Keep It Simple, Stupid (Fais Simple, Gros Malin :p) Il faut le support de tout le monde. Sans l’aval du manager, les outils ne seront peut-être pas là et tout le monde ne fonctionnera pas sur le même mode. Donc impossible de livrer de façon incrémentale au métier. Si le métier ne suit pas, la communication sera difficile et les specs pas ou mal respectées. A noter quand même qu’on n’a pas forcément besoin de specs détaillées ou d’outils perfectionnés pour commencer à faire les tests simples…
  10. En premier lieu, les frameworks de tests unitaires sont un passage obligé. Ils diffèrent selon les langages et les équipes de dev mais en maîtriser un ou deux est fortement recommandé. Idem pour le mocking et tout ce qui est injection de dépendances (http://en.wikipedia.org/wiki/Dependency_inversion_principle). En termes d’outils, il existe beaucoup de plug-ins aux divers environnements de dev qui facilitent la création et le suivi de tests. Certains sont même fournis avec le framework de test (ex : nUnit) ou carrément avec l’IDE. Les katas, comme dans les arts martiaux, représentent des exercices simples dont le but est d’assimiler une ou plusieurs techniques. C’est pareil en dev : en réalisant un exercice régulièrement en se tenant au TDD, on va finir par bien comprendre les concepts derrière.
  11. Quand je suis entré en finance, on m’a dit : “tu vas voir, en finance ils ont environ 10 ans de retard sur la gestion des projets informatiques”. Ca se vérifie aujourd’hui. Le problème c’est qu’en tant que consultant, il faut savoir se tenir à la page. TDD est un process important, ce n’est pas un effet de mode, il est là pour rester. Il est donc crucial de le maîtriser sous peine de devenir un dino à moyen terme. L’avantage c’est que ce n’est pas si dur ; en 2 semaines à pratiquer pendant 30 minutes par jour sur des exercices simples, on connaît bien les rouages.
  12. CodeWars est très sympa et une bonne source d’inspiration mais est orienté résultat : à vous de vous astreindre à utiliser le TDD lors de l’élaboration de la solution.