Ecrire un code TESTABLE

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

Transcript

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