Ecrire un Code
TESTABLE
Mohamed Cherif BOUCHELAGHEM
Twitter: @cherif_b
Problème
Code difficile à changer
Bugs difficile à détecter
Solution
ingle responsability principle
pen/Closed Closed principle
iskov substitution principle
nterface Segregation prin...
Robert C. Martin (Uncle BOB)
L’auteur du livre ‘Clean code’ (Coder proprement)
Single responsability
principle
SOLID « S » Principe de Responsabilité unique
Une classe n’a qu’une, et une seule,
raison de changer
SOLID « S »
Principe de Responsabilité unique
SOLID « S »
Principe de Responsabilité unique
• La solution est de diviser la classe en deux , une
pour communication avec...
OPEN/CLOSED
PRINCIPLE
Le code doit être ouvert à l’extension
mais fermé à la modification.
SOLID « O »
OPEN/CLOSED PRINCIPLE
SOLID « O »
OPEN/CLOSED PRINCIPLE
Problème si on veux rajouter un autre réseau social
switch/case n’est pas une solution (...
SOLID « O »
OPEN/CLOSED PRINCIPLE
SOLID « O »
OPEN/CLOSED PRINCIPLE
Augmente la testabilité du code
Chaque service peut être testé séparément
LISKOV Substitution
Principle
SOLID « L »
LISKOV Substitution Principle
Si “S” est un sous-type de “T”, alors tout objet de type “T” peut être
remplacé ...
Violation du principe Carre n’est pas un
rectangle
SOLID « L »
LISKOV Substitution Principle
Implémentation du principe avec le design pattern Adaptateur
SOLID « L »
LISKOV Substitution Principle
Interface Segregation
Principle
SOLID « I »
Interface Segregation Principle
Quand on envoie un SMS est ce qu’on a besoin d’email??
SOLID « I »
Interface Segregation Principle
SRP respecté, moins de tests par classe, moins de dépendance entre méthodes
Dependency Injection
principle
SOLID « D »
Dependency Injection Principle
Injection de dépendance
• SRP pour les acteurs et l’architecture de haut
niveau
• OCP pour la conception et l’extension des
fonctionnalités
• LSP ...
L’application est un ensemble de
briques découplées (Composants)
Si SOLID sont bien
appliqués
On va constater que
Le Web, c’est juste un système de
livraison (PIPE)
La base de données c’est qu’un
détail
Le framework n’est pas le centre
du monde de notre application
Autrement dit
Autrement dit
Le framework nous aide juste dans
ces aspects de l’application
Logique métier est le
cœur de notre application
Tests Unitaire (Unit tests)
Choisissez votre aventure
Questions
Références
Ecrire un code Testable
Prochain SlideShare
Chargement dans…5
×

Ecrire un code Testable

910 vues

Publié le

Comment écrire un code testable et éviter les erreurs de régression et assurer une application maintenable a long terme.
Une conférence qui été dans l'event Call4Tech a Constantine (Algérie) le 09/05/2014

Publié dans : Ingénierie
0 commentaire
7 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
910
Sur SlideShare
0
Issues des intégrations
0
Intégrations
8
Actions
Partages
0
Téléchargements
11
Commentaires
0
J’aime
7
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Ecrire un code Testable

  1. 1. Ecrire un Code TESTABLE Mohamed Cherif BOUCHELAGHEM Twitter: @cherif_b
  2. 2. Problème Code difficile à changer Bugs difficile à détecter
  3. 3. Solution ingle responsability principle pen/Closed Closed principle iskov substitution principle nterface Segregation principle ependency injection
  4. 4. Robert C. Martin (Uncle BOB) L’auteur du livre ‘Clean code’ (Coder proprement)
  5. 5. Single responsability principle
  6. 6. SOLID « S » Principe de Responsabilité unique Une classe n’a qu’une, et une seule, raison de changer
  7. 7. SOLID « S » Principe de Responsabilité unique
  8. 8. SOLID « S » Principe de Responsabilité unique • La solution est de diviser la classe en deux , une pour communication avec le web service et la deuxième pour passer les donner à notre objet • Le web service sera ‘Mocké’ dans le test facilement • Des méthodes plus petites, moins de dépendances entre les méthodes et moins de régression
  9. 9. OPEN/CLOSED PRINCIPLE
  10. 10. Le code doit être ouvert à l’extension mais fermé à la modification. SOLID « O » OPEN/CLOSED PRINCIPLE
  11. 11. SOLID « O » OPEN/CLOSED PRINCIPLE Problème si on veux rajouter un autre réseau social switch/case n’est pas une solution (anti-pattern)
  12. 12. SOLID « O » OPEN/CLOSED PRINCIPLE
  13. 13. SOLID « O » OPEN/CLOSED PRINCIPLE Augmente la testabilité du code Chaque service peut être testé séparément
  14. 14. LISKOV Substitution Principle
  15. 15. SOLID « L » LISKOV Substitution Principle Si “S” est un sous-type de “T”, alors tout objet de type “T” peut être remplacé par un objet de type “S” sans altérer les propriétés désirables du programme concerné.
  16. 16. Violation du principe Carre n’est pas un rectangle SOLID « L » LISKOV Substitution Principle
  17. 17. Implémentation du principe avec le design pattern Adaptateur SOLID « L » LISKOV Substitution Principle
  18. 18. Interface Segregation Principle
  19. 19. SOLID « I » Interface Segregation Principle Quand on envoie un SMS est ce qu’on a besoin d’email??
  20. 20. SOLID « I » Interface Segregation Principle SRP respecté, moins de tests par classe, moins de dépendance entre méthodes
  21. 21. Dependency Injection principle
  22. 22. SOLID « D » Dependency Injection Principle Injection de dépendance
  23. 23. • SRP pour les acteurs et l’architecture de haut niveau • OCP pour la conception et l’extension des fonctionnalités • LSP pour l’héritage et sous typage • ISP pour la communication entre la logique métier et les clients (MVC, applications tierces…etc) • DIC pour le découplage, En résumé
  24. 24. L’application est un ensemble de briques découplées (Composants)
  25. 25. Si SOLID sont bien appliqués
  26. 26. On va constater que
  27. 27. Le Web, c’est juste un système de livraison (PIPE)
  28. 28. La base de données c’est qu’un détail
  29. 29. Le framework n’est pas le centre du monde de notre application
  30. 30. Autrement dit
  31. 31. Autrement dit Le framework nous aide juste dans ces aspects de l’application
  32. 32. Logique métier est le cœur de notre application
  33. 33. Tests Unitaire (Unit tests)
  34. 34. Choisissez votre aventure
  35. 35. Questions
  36. 36. Références

×