SlideShare une entreprise Scribd logo
POURQUOIVOUS NE POUVEZ PAS TESTER VOTRE
CODE
RÉMI LESIEUR
• Coach
– Software Craftsmanship
– DevOps
– Agile
• DevOps
• Dev FullStack (mais plutôt back)
PETITE HISTOIRE
Nous on a une architecture compliquée avec 8 bases de données synchronisées et 15 web services
parallèles qui appellent 50 APIs concurrentes pour lancer un workflow écrit en FORTRAN par un stagiaire en
92 …
On ne peut pas implémenter aussi facilement des tests.
LES STANDARDS INSISTENT SUR LES TESTS DU CODE
• Un Standard ?
– La meilleure façon identifiée de réaliser une action
• Continuous Testing
– eXtreme Programming
– DevOps
ON A UNE ARCHITECTURE TROP COMPLEXE
• Nous, on a une base de données !
• Et puis des fichiers !
• Sur un partage réseau !
• Et on s’interface avec d’autres systèmes / progiciels !
 Vous avez pensé aux doublures de tests (Ou mocks) ?
 Mockito en Java
 Moq en .Net
 Revoir l’architecture du produit
C’EST TROP DE BOULOT / CA COÛTE TROP CHER / ON N’A PAS LE TEMPS
• On doit livrer les features au client, c’est plus important
• Le client ne voudra jamais payer pour ça
 Quel est votre temps passé à corriger des bugs ?
 Ca coûte combien une phase de recette chez vous ?
 Mettez en lumière le temps passé à maintenir le code existant vs les nouvelles features.
 Définissez un plan de reprise de la dette technique.
ON NE VOIT PAS L’INTÉRÊT
• On a déjà la Q.A. (Quality Insurance / Assurance Qualité) qui teste
• Si on fait ça, la Q.A. va râler parce qu’on prend son boulot
 Est-ce le boulot de la Q.A. de s’assurer que l’application soit stable ?
 Est-ce qu’elle vérifie systématiquement toutes les features avant livraison ?
 Ce n’est pas un peu redondant ?
 Tester “à priori” de la QA, c’est faciliter son travail
 Elle cherche elle-même à automatiser ses tests
 Les intégrer dans la réflexion ? Cf. Cucumber, FitNesse, …
ON NE VOIT PAS L’INTÉRÊT (V2)
• On n’est pas payés pour tester
• Je m’en fous c’est pas mon code
 Retour à la question sur le temps passé sur les bugfix et les phases de recette
 Vous pensez aux évolutions d’architecture ?
 Se référer au cadre (XP, cycle en V) choisi par l’équipe, il y a sûrement une phase dédiée aux tests
 Si vous n’en n’avez pas, il serait intéressant de s’y pencher
 Si le cadre n’en parle pas, peut-être êtes vous trop haut niveau (organisationnel type Kanban)
TESTER SON CODE, CE N’EST PAS MAGIQUE
• Temps
• Investissement
• Parfois ralentir / limiter les features pour privilégier le refactor
• Investissement à long terme
– Entretient / révision
– Le « risque de ne pas faire » est souvent invisible
• Nombre de bugfix / hotfix
• Temps de MEP
• TTM
• Ne pas forcer l’équipe, les amener à comprendre pourquoi c’est important et ce qu’ils y gagnent
• Ne pas les laisser seuls (katas, formation, coaching)
– Risque de laisser l’équipe dériver

Contenu connexe

Tendances

4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel
lauraty3204
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Denis Voituron
 
C'est quoi, du bon code ?
C'est quoi, du bon code ?C'est quoi, du bon code ?
C'est quoi, du bon code ?
Rémi Lesieur
 
Tests automatisés java script
Tests automatisés java scriptTests automatisés java script
Tests automatisés java script
Pascal Laurin
 
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAgile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Association Agile Nantes
 
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
Jean-Philippe Briend
 
7 astuces pour améliorer vos tests unitaires
7 astuces pour améliorer vos tests unitaires7 astuces pour améliorer vos tests unitaires
7 astuces pour améliorer vos tests unitaires
Pascal Laurin
 
Tdd en action - découverte
Tdd en action - découverteTdd en action - découverte
Tdd en action - découverte
Eric Mignot
 
Tests Dinterface SWT
Tests Dinterface SWTTests Dinterface SWT
Tests Dinterface SWT
Eric Le Merdy
 
Valider par des tests - Blend
Valider par des tests - BlendValider par des tests - Blend
Valider par des tests - Blend
Christophe Villeneuve
 
Cerberus, un outil pour l'automatisation des tests fonctionnels
Cerberus, un outil pour l'automatisation des tests fonctionnelsCerberus, un outil pour l'automatisation des tests fonctionnels
Cerberus, un outil pour l'automatisation des tests fonctionnels
Aurélien Bourdon
 
Cerberus Testing
Cerberus TestingCerberus Testing
Cerberus Testing
CIVEL Benoit
 
[Agile Testing Day] Techniques avancées de tests
[Agile Testing Day] Techniques avancées de tests[Agile Testing Day] Techniques avancées de tests
[Agile Testing Day] Techniques avancées de tests
Cellenza
 
Robot Framework Introduction
Robot Framework IntroductionRobot Framework Introduction
Robot Framework Introduction
laurent bristiel
 
[Agile Testing Day] Tests de charge
[Agile Testing Day] Tests de charge [Agile Testing Day] Tests de charge
[Agile Testing Day] Tests de charge
Cellenza
 
Transition Agile @ Meetic
Transition Agile @ MeeticTransition Agile @ Meetic
Transition Agile @ Meetic
meeticTech
 
XebiConFr 15 - Développer dans le Cloud
XebiConFr 15 - Développer dans le CloudXebiConFr 15 - Développer dans le Cloud
XebiConFr 15 - Développer dans le Cloud
Publicis Sapient Engineering
 
Symphonie pour PHP industrialisé en agilité majeure
Symphonie pour PHP industrialisé en agilité majeureSymphonie pour PHP industrialisé en agilité majeure
Symphonie pour PHP industrialisé en agilité majeure
Jonathan Bonzy
 
Migrer de framework : de la réflexion à l'action
Migrer de framework : de la réflexion à l'actionMigrer de framework : de la réflexion à l'action
Migrer de framework : de la réflexion à l'action
Xavier Leune
 
Les tests behat par la pratique
Les tests behat par la pratiqueLes tests behat par la pratique
Les tests behat par la pratique
Guilhem Bourgoin
 

Tendances (20)

4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
 
C'est quoi, du bon code ?
C'est quoi, du bon code ?C'est quoi, du bon code ?
C'est quoi, du bon code ?
 
Tests automatisés java script
Tests automatisés java scriptTests automatisés java script
Tests automatisés java script
 
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAgile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
 
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
 
7 astuces pour améliorer vos tests unitaires
7 astuces pour améliorer vos tests unitaires7 astuces pour améliorer vos tests unitaires
7 astuces pour améliorer vos tests unitaires
 
Tdd en action - découverte
Tdd en action - découverteTdd en action - découverte
Tdd en action - découverte
 
Tests Dinterface SWT
Tests Dinterface SWTTests Dinterface SWT
Tests Dinterface SWT
 
Valider par des tests - Blend
Valider par des tests - BlendValider par des tests - Blend
Valider par des tests - Blend
 
Cerberus, un outil pour l'automatisation des tests fonctionnels
Cerberus, un outil pour l'automatisation des tests fonctionnelsCerberus, un outil pour l'automatisation des tests fonctionnels
Cerberus, un outil pour l'automatisation des tests fonctionnels
 
Cerberus Testing
Cerberus TestingCerberus Testing
Cerberus Testing
 
[Agile Testing Day] Techniques avancées de tests
[Agile Testing Day] Techniques avancées de tests[Agile Testing Day] Techniques avancées de tests
[Agile Testing Day] Techniques avancées de tests
 
Robot Framework Introduction
Robot Framework IntroductionRobot Framework Introduction
Robot Framework Introduction
 
[Agile Testing Day] Tests de charge
[Agile Testing Day] Tests de charge [Agile Testing Day] Tests de charge
[Agile Testing Day] Tests de charge
 
Transition Agile @ Meetic
Transition Agile @ MeeticTransition Agile @ Meetic
Transition Agile @ Meetic
 
XebiConFr 15 - Développer dans le Cloud
XebiConFr 15 - Développer dans le CloudXebiConFr 15 - Développer dans le Cloud
XebiConFr 15 - Développer dans le Cloud
 
Symphonie pour PHP industrialisé en agilité majeure
Symphonie pour PHP industrialisé en agilité majeureSymphonie pour PHP industrialisé en agilité majeure
Symphonie pour PHP industrialisé en agilité majeure
 
Migrer de framework : de la réflexion à l'action
Migrer de framework : de la réflexion à l'actionMigrer de framework : de la réflexion à l'action
Migrer de framework : de la réflexion à l'action
 
Les tests behat par la pratique
Les tests behat par la pratiqueLes tests behat par la pratique
Les tests behat par la pratique
 

Similaire à Pourquoi vous ne pouvez pas tester votre code

Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29
Elapse Technologies
 
Usine Logicielle 2013
Usine Logicielle 2013Usine Logicielle 2013
Usine Logicielle 2013
Stéphane Liétard
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
Christophe HERAL
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
CGI Québec Formation
 
La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !
Lucian Precup
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
French Scrum User Group
 
Azure DevOps Tests Plan
Azure DevOps Tests PlanAzure DevOps Tests Plan
Azure DevOps Tests Plan
Denis Voituron
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Agile Tour 2009 Québec
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisés
Djamel Zouaoui
 
Formation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratifFormation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratif
kemenaran
 
Dev opsday case study
Dev opsday   case studyDev opsday   case study
Dev opsday case study
Radoine Douhou
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
Agile Tour 2009 Québec
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
Frederic Hardy
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testable
martinsson
 
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogèneMise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Grégory Ott
 
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogèneMise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Microsoft Technet France
 
Les nouveautés de Visual Studio 11
Les nouveautés de Visual Studio 11Les nouveautés de Visual Studio 11
Les nouveautés de Visual Studio 11
Microsoft
 
Ez18n Annotation Processing Tool in a nutshell
Ez18n Annotation Processing Tool in a nutshellEz18n Annotation Processing Tool in a nutshell
Ez18n Annotation Processing Tool in a nutshell
gdigugli
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
Clement Bouillier
 

Similaire à Pourquoi vous ne pouvez pas tester votre code (20)

Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29
 
Usine Logicielle 2013
Usine Logicielle 2013Usine Logicielle 2013
Usine Logicielle 2013
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
 
La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
 
Azure DevOps Tests Plan
Azure DevOps Tests PlanAzure DevOps Tests Plan
Azure DevOps Tests Plan
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisés
 
Formation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratifFormation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratif
 
Dev opsday case study
Dev opsday   case studyDev opsday   case study
Dev opsday case study
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testable
 
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogèneMise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogène
 
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogèneMise en œuvre de TFS 2010 dans un environnement technologique hétérogène
Mise en œuvre de TFS 2010 dans un environnement technologique hétérogène
 
Les nouveautés de Visual Studio 11
Les nouveautés de Visual Studio 11Les nouveautés de Visual Studio 11
Les nouveautés de Visual Studio 11
 
Ez18n Annotation Processing Tool in a nutshell
Ez18n Annotation Processing Tool in a nutshellEz18n Annotation Processing Tool in a nutshell
Ez18n Annotation Processing Tool in a nutshell
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
 
Lunch learn 5 sep2013
Lunch learn 5 sep2013Lunch learn 5 sep2013
Lunch learn 5 sep2013
 

Pourquoi vous ne pouvez pas tester votre code

  • 1. POURQUOIVOUS NE POUVEZ PAS TESTER VOTRE CODE
  • 2. RÉMI LESIEUR • Coach – Software Craftsmanship – DevOps – Agile • DevOps • Dev FullStack (mais plutôt back)
  • 3. PETITE HISTOIRE Nous on a une architecture compliquée avec 8 bases de données synchronisées et 15 web services parallèles qui appellent 50 APIs concurrentes pour lancer un workflow écrit en FORTRAN par un stagiaire en 92 … On ne peut pas implémenter aussi facilement des tests.
  • 4. LES STANDARDS INSISTENT SUR LES TESTS DU CODE • Un Standard ? – La meilleure façon identifiée de réaliser une action • Continuous Testing – eXtreme Programming – DevOps
  • 5. ON A UNE ARCHITECTURE TROP COMPLEXE • Nous, on a une base de données ! • Et puis des fichiers ! • Sur un partage réseau ! • Et on s’interface avec d’autres systèmes / progiciels !  Vous avez pensé aux doublures de tests (Ou mocks) ?  Mockito en Java  Moq en .Net  Revoir l’architecture du produit
  • 6. C’EST TROP DE BOULOT / CA COÛTE TROP CHER / ON N’A PAS LE TEMPS • On doit livrer les features au client, c’est plus important • Le client ne voudra jamais payer pour ça  Quel est votre temps passé à corriger des bugs ?  Ca coûte combien une phase de recette chez vous ?  Mettez en lumière le temps passé à maintenir le code existant vs les nouvelles features.  Définissez un plan de reprise de la dette technique.
  • 7. ON NE VOIT PAS L’INTÉRÊT • On a déjà la Q.A. (Quality Insurance / Assurance Qualité) qui teste • Si on fait ça, la Q.A. va râler parce qu’on prend son boulot  Est-ce le boulot de la Q.A. de s’assurer que l’application soit stable ?  Est-ce qu’elle vérifie systématiquement toutes les features avant livraison ?  Ce n’est pas un peu redondant ?  Tester “à priori” de la QA, c’est faciliter son travail  Elle cherche elle-même à automatiser ses tests  Les intégrer dans la réflexion ? Cf. Cucumber, FitNesse, …
  • 8. ON NE VOIT PAS L’INTÉRÊT (V2) • On n’est pas payés pour tester • Je m’en fous c’est pas mon code  Retour à la question sur le temps passé sur les bugfix et les phases de recette  Vous pensez aux évolutions d’architecture ?  Se référer au cadre (XP, cycle en V) choisi par l’équipe, il y a sûrement une phase dédiée aux tests  Si vous n’en n’avez pas, il serait intéressant de s’y pencher  Si le cadre n’en parle pas, peut-être êtes vous trop haut niveau (organisationnel type Kanban)
  • 9. TESTER SON CODE, CE N’EST PAS MAGIQUE • Temps • Investissement • Parfois ralentir / limiter les features pour privilégier le refactor • Investissement à long terme – Entretient / révision – Le « risque de ne pas faire » est souvent invisible • Nombre de bugfix / hotfix • Temps de MEP • TTM • Ne pas forcer l’équipe, les amener à comprendre pourquoi c’est important et ce qu’ils y gagnent • Ne pas les laisser seuls (katas, formation, coaching) – Risque de laisser l’équipe dériver

Notes de l'éditeur

  1. XP : Méthode de développement logiciel basé sur des phases de plus en plus courtes Mois -> Secondes. DevOps : ensemble de pratiques (dont dev) intégrant le déploiement et l’intégration continue, encourageant les tests automatiques (dont de code)
  2. Elle doit s’assurer que le produit réponde au mieux au besoin exprimé
  3. Passer en containerisation (Docker, Kubernetes) avec une archi test-ready est plus simple