Comment rendre testable du code qui ne l’est pas ? 
Christophe HERAL 
@ChrisHeral 
Neotech Solutions - Bordeaux
Qui suis-je ? 
• Consultant .NET à Bordeaux 
• Agiliste 
Et surtout : 
• Artisan logiciel
Une attention continue à l'excellence 
technique et à une bonne conception 
renforce l’Agilité. 
Les meilleures architectu...
Code existant 
Méconnaissance des méthodes d’ingénierie 
Fortement couplé / trop de responsabilités 
Sans tests -> Diffici...
Les choses à ne pas faire : STUPID 
Singleton 
Tight Coupling 
Untestable 
Premature Optimization 
Indescriptive Naming 
D...
Clean Code 
Définition : 
1. Passe tous les tests 
2. N’est pas redondant 
3. Exprime clairement les intentions du program...
Clean Code – Comment y parvenir 
TDD 
Principes SOLID 
KISS / YAGNI / DRY 
Règle du boy-scout : « Toujours laisser le code...
SOLID : 5 principes de base 
Principes d’architecture logicielle en programmation orientée objet 
Objectif : permettre un ...
SRP - Single Responsability Principle 
(Responsabilité unique) 
« Si une classe a plus d'une responsabilité, alors 
ces re...
SRP - Avant
SRP - Après
OCP – Open/Closed Principle 
(Ouvert/fermé) 
« Les modules qui se conforment au principe ouvert/fermé 
ont deux attributs ...
OCP – Avant
OCP – Après
LSP – Liskov Substitution Principle 
(Substitution de Liskov) 
« Les sous-types doivent être remplaçables 
par leur type d...
LSP – Avant
LSP – Après
ISP – Interface Segregation Principle 
(Séparation des interfaces) 
Les clients d'une entité logicielle ne doivent 
pas av...
ISP – Avant
ISP – Après
DIP – Dependency Inversion Principle 
(Inversion des dépendances) 
Principe d’Hollywood : 
« Ne nous appelez pas, nous vou...
DIP – Avant
DIP – Après
SOLID en 5 images
Soyez indépendants ! 
Ne pas dépendre d’un service / une API externe 
Ne pas dépendre d’une base de données 
Ne pas dépend...
Simuler des dépendances 
Isolation = Fondamental 
Rend le test véritablement unitaire 
SUT 
Dépendance 
Doublure 
Interfac...
Code écrit par Kévin remasterisé
DRY – Don’t Repeat Yourself 
« Dans un système, toute connaissance doit avoir une 
représentation unique, non-ambiguë, fai...
Composition over inheritance 
• « Is a » VS « Has a » 
• Meilleure testabilité 
• Casse l’encapsulation 
• Nécessaire pour...
Code Smells (« Odeurs du code ») 
• Méthodes longues / Grosses classes 
• Longue liste de paramètres 
• Utilisation de swi...
Repérer les Code Smells 
• Relecture de code 
-> Pair Programming 
-> « Clean Code Cheat Sheet » de Urs Enzler 
• Analyse ...
Pour aller plus loin…
Merci !
Prochain SlideShare
Chargement dans…5
×

[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

1 414 vues

Publié le

Les principes SOLID font partie des bases de la programmation orientée objet. Cependant, qui n'est jamais intervenu sur un projet avec l'ensemble du code fortement couplé ? Avec de ce fait de grandes difficultés à le tester unitairement ? L'objectif de cette présentation est de démontrer sur un cas d'usage comment l'utilisation d'interfaces et l'injection de dépendances va nous permettre d'améliorer ce code et de le rendre testable.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

  1. 1. Comment rendre testable du code qui ne l’est pas ? Christophe HERAL @ChrisHeral Neotech Solutions - Bordeaux
  2. 2. Qui suis-je ? • Consultant .NET à Bordeaux • Agiliste Et surtout : • Artisan logiciel
  3. 3. Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
  4. 4. Code existant Méconnaissance des méthodes d’ingénierie Fortement couplé / trop de responsabilités Sans tests -> Difficilement testable Architecture classique en couches
  5. 5. Les choses à ne pas faire : STUPID Singleton Tight Coupling Untestable Premature Optimization Indescriptive Naming Duplication
  6. 6. Clean Code Définition : 1. Passe tous les tests 2. N’est pas redondant 3. Exprime clairement les intentions du programmeur 4. Minimise le nombre d’entités (classes et méthodes) “Writing code that a computer can understand is science, but writing code another programmer can understand is an art” - Jason Gorman
  7. 7. Clean Code – Comment y parvenir TDD Principes SOLID KISS / YAGNI / DRY Règle du boy-scout : « Toujours laisser le code plus propre que vous ne l’avez trouvé en arrivant. »
  8. 8. SOLID : 5 principes de base Principes d’architecture logicielle en programmation orientée objet Objectif : permettre un développement plus fiable et plus robuste S Responsabilité unique (Single responsibility principle) O Ouvert/fermé (Open/closed principle) L Substitution de Liskov (Liskov Substitution Principle) I Ségrégation des interfaces (Interface Segregation Principle) D Inversion des dépendances (Dependency Inversion Principle)
  9. 9. SRP - Single Responsability Principle (Responsabilité unique) « Si une classe a plus d'une responsabilité, alors ces responsabilités deviennent couplées. (…) » - Robert C. Martin
  10. 10. SRP - Avant
  11. 11. SRP - Après
  12. 12. OCP – Open/Closed Principle (Ouvert/fermé) « Les modules qui se conforment au principe ouvert/fermé ont deux attributs principaux : 1 - Ils sont "Ouverts pour l'extension". (...) 2 - Ils sont "Fermés à la modification". (…) » - Robert C. Martin
  13. 13. OCP – Avant
  14. 14. OCP – Après
  15. 15. LSP – Liskov Substitution Principle (Substitution de Liskov) « Les sous-types doivent être remplaçables par leur type de base. » - Robert C. Martin
  16. 16. LSP – Avant
  17. 17. LSP – Après
  18. 18. ISP – Interface Segregation Principle (Séparation des interfaces) Les clients d'une entité logicielle ne doivent pas avoir à dépendre d'une interface qu'ils n'utilisent pas.
  19. 19. ISP – Avant
  20. 20. ISP – Après
  21. 21. DIP – Dependency Inversion Principle (Inversion des dépendances) Principe d’Hollywood : « Ne nous appelez pas, nous vous appellerons. » Dépendance A B A I Dépendance Implémente B
  22. 22. DIP – Avant
  23. 23. DIP – Après
  24. 24. SOLID en 5 images
  25. 25. Soyez indépendants ! Ne pas dépendre d’un service / une API externe Ne pas dépendre d’une base de données Ne pas dépendre de données de production Ne pas dépendre du jour et de l’heure
  26. 26. Simuler des dépendances Isolation = Fondamental Rend le test véritablement unitaire SUT Dépendance Doublure Interface On simule = l’implémentation attendue Automatisation avec un framework de mocking (ex : Moq)
  27. 27. Code écrit par Kévin remasterisé
  28. 28. DRY – Don’t Repeat Yourself « Dans un système, toute connaissance doit avoir une représentation unique, non-ambiguë, faisant autorité. » - Andy Hunt et Dave Thomas (The Pragmatic Programmer)
  29. 29. Composition over inheritance • « Is a » VS « Has a » • Meilleure testabilité • Casse l’encapsulation • Nécessaire pour l’application de certains patterns
  30. 30. Code Smells (« Odeurs du code ») • Méthodes longues / Grosses classes • Longue liste de paramètres • Utilisation de switch • GOTO / Codes de retour d’erreur • Noms de méthodes avec ET/OU • Code dupliqué • Code mort • Navigation transitive • Nombres magiques • Généralité spéculative • Commentaires • Séparation verticale • Chirurgie avec fusil à pompe • Héritage parallèle
  31. 31. Repérer les Code Smells • Relecture de code -> Pair Programming -> « Clean Code Cheat Sheet » de Urs Enzler • Analyse statique de code -> Repère des erreurs de conception / programmation -> Outils : FxCop, StyleCop, Resharper, NDepend
  32. 32. Pour aller plus loin…
  33. 33. Merci !

×