Ecrire un code Testable
Télécharger en tant que PPTX, PDF7 j'aime1,394 vues
Le document traite des principes SOLID pour écrire un code testable et facilement maintenable. Chaque principe est expliqué en lien avec la réduction des dépendances et l'amélioration de la testabilité, soulevant l'importance de la responsabilité unique et de l'injection de dépendances. L'auteur souligne que l'application doit être conçue comme un ensemble de composants découplés, où la logique métier est au cœur.
Ecrire un code Testable
- 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)
- 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
- 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
- 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
- 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
- 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)
- 36. Questions
- 37. Références