Ecrire un Code TESTABLEMohamed 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 principle

ependency injection

Robert C. Martin (Uncle BOB)

L’auteur du livre ‘Clean code’ (Coder proprement)

Single responsabilityprinciple

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 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

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 (anti-pattern)

SOLID « O » OPEN/CLOSED PRINCIPLE

SOLID « O » OPEN/CLOSED PRINCIPLE

Augmente la testabilité du codeChaque 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é par un objet de type “S” sans altérer les propriétés désirables du

programme concerné.

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 SegregationPrinciple

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 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é

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