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

1. Ecrire un Code
TESTABLE
Mohamed Cherif BOUCHELAGHEM
Twitter: @cherif_b

2. Problème
Code difficile à changer
Bugs difficile à détecter

3. Solution
ingle responsability principle
pen/Closed Closed principle
iskov substitution principle
nterface Segregation principle
ependency injection

4. Robert C. Martin (Uncle BOB)
L’auteur du livre ‘Clean code’ (Coder proprement)

5. Single responsability
principle

6. SOLID « S » Principe de Responsabilité unique
Une classe n’a qu’une, et une seule,
raison de changer

7. SOLID « S »
Principe de Responsabilité unique

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. OPEN/CLOSED
PRINCIPLE

10. Le code doit être ouvert à l’extension
mais fermé à la modification.
SOLID « O »
OPEN/CLOSED PRINCIPLE

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. SOLID « O »
OPEN/CLOSED PRINCIPLE

13. SOLID « O »
OPEN/CLOSED PRINCIPLE
Augmente la testabilité du code
Chaque service peut être testé séparément

14. LISKOV Substitution
Principle

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. Violation du principe Carre n’est pas un
rectangle
SOLID « L »
LISKOV Substitution Principle

17. Implémentation du principe avec le design pattern Adaptateur
SOLID « L »
LISKOV Substitution Principle

18. Interface Segregation
Principle

19. SOLID « I »
Interface Segregation Principle
Quand on envoie un SMS est ce qu’on a besoin d’email??

20. SOLID « I »
Interface Segregation Principle
SRP respecté, moins de tests par classe, moins de dépendance entre méthodes

21. Dependency Injection
principle

23. SOLID « D »
Dependency Injection Principle
Injection de dépendance

24. • 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é

25. L’application est un ensemble de
briques découplées (Composants)

26. Si SOLID sont bien
appliqués

27. On va constater que

28. Le Web, c’est juste un système de
livraison (PIPE)

29. La base de données c’est qu’un
détail

30. Le framework n’est pas le centre
du monde de notre application

31. Autrement dit

32. Autrement dit
Le framework nous aide juste dans
ces aspects de l’application

33. Logique métier est le
cœur de notre application

34. Tests Unitaire (Unit tests)

35. Choisissez votre aventure

36. Questions

37. Références