Ecrire un code TESTABLE

Slide 1

Slide 1 text

Ecrire un Code TESTABLE Mohamed Cherif BOUCHELAGHEM Twitter: @cherif_b

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Single responsability principle

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

SOLID « S » Principe de Responsabilité unique

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

OPEN/CLOSED PRINCIPLE

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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)

Slide 12

Slide 12 text

SOLID « O » OPEN/CLOSED PRINCIPLE

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

LISKOV Substitution Principle

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Violation du principe Carre n’est pas un rectangle SOLID « L » LISKOV Substitution Principle

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Interface Segregation Principle

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Dependency Injection principle

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Si SOLID sont bien appliqués

Slide 27

Slide 27 text

On va constater que

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Autrement dit

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Tests Unitaire (Unit tests)

Slide 35

Slide 35 text

Choisissez votre aventure

Slide 36

Slide 36 text

Questions

Slide 37

Slide 37 text

Références