33
Comment rendre testable du code qui ne l’est pas ? Christophe HERAL @ChrisHeral Neotech Solutions - Bordeaux

[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Embed Size (px)

DESCRIPTION

Les principes SOLID font partie des bases de la programmation orientée objet. Cependant, qui n'est jamais intervenu sur un projet avec l'ensemble du code fortement couplé ? Avec de ce fait de grandes difficultés à le tester unitairement ? L'objectif de cette présentation est de démontrer sur un cas d'usage comment l'utilisation d'interfaces et l'injection de dépendances va nous permettre d'améliorer ce code et de le rendre testable.

Citation preview

Page 1: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Comment rendre testable du code qui ne l’est pas ?

Christophe HERAL@ChrisHeral

Neotech Solutions - Bordeaux

Page 2: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Qui suis-je ?

• Consultant .NET à Bordeaux

• Agiliste

Et surtout :

• Artisan logiciel

Page 3: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Une attention continue à l'excellence technique et à une bonne conception

renforce l’Agilité.

Les meilleures architectures, spécifications et conceptions

émergent d'équipes auto-organisées.

Page 4: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Code existant

Méconnaissance des méthodes d’ingénierie

Fortement couplé / trop de responsabilités

Sans tests -> Difficilement testable

Architecture classique en couches

Page 5: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Les choses à ne pas faire : STUPID

Singleton

Tight Coupling

Untestable

Premature Optimization

Indescriptive Naming

Duplication

Page 6: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Clean Code

Définition :

1. Passe tous les tests

2. N’est pas redondant

3. Exprime clairement les intentions du programmeur

4. Minimise le nombre d’entités (classes et méthodes)

“Writing code that a computer can understand is

science, but writing code another programmer can

understand is an art” - Jason Gorman

Page 7: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Clean Code – Comment y parvenir

TDD

Principes SOLID

KISS / YAGNI / DRY

Règle du boy-scout : « Toujours laisser le code plus propre que vous ne l’avez trouvé en arrivant. »

Page 8: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

SOLID : 5 principes de base

Principes d’architecture logicielle en programmation orientée objet

Objectif : permettre un développement plus fiable et plus robuste

S Responsabilité unique(Single responsibility principle)

O Ouvert/fermé(Open/closed principle)

L Substitution de Liskov(Liskov Substitution Principle)

I Ségrégation des interfaces(Interface Segregation Principle)

D Inversion des dépendances (Dependency Inversion Principle)

Page 9: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

SRP - Single Responsability Principle(Responsabilité unique)

« Si une classe a plus d'une responsabilité, alors ces responsabilités deviennent couplées. (…) »

- Robert C. Martin

Page 10: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

SRP - Avant

Page 11: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

SRP - Après

Page 12: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

OCP – Open/Closed Principle(Ouvert/fermé)

« Les modules qui se conforment au principe ouvert/fermé ont deux attributs principaux :

1 - Ils sont "Ouverts pour l'extension". (...)

2 - Ils sont "Fermés à la modification". (…) »- Robert C. Martin

Page 13: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

OCP – Avant

Page 14: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

OCP – Après

Page 15: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

LSP – Liskov Substitution Principle(Substitution de Liskov)

« Les sous-types doivent être remplaçables par leur type de base. » - Robert C. Martin

Page 16: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

LSP – Avant

Page 17: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

LSP – Après

Page 18: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

ISP – Interface Segregation Principle(Séparation des interfaces)

Les clients d'une entité logicielle ne doivent pas avoir à dépendre d'une interface qu'ils n'utilisent pas.

Page 19: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

ISP – Avant

Page 20: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

ISP – Après

Page 21: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

DIP – Dependency Inversion Principle(Inversion des dépendances)

Principe d’Hollywood :

« Ne nous appelez pas, nous vous appellerons. »

A B

Dépendance

A I

B

ImplémenteDépendance

Page 22: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

DIP – Avant

Page 23: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

DIP – Après

Page 24: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

SOLID en 5 images

Page 25: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Ne pas dépendre d’un service / une API externe

Ne pas dépendre d’une base de données

Ne pas dépendre de données de production

Ne pas dépendre du jour et de l’heure

Soyez indépendants !

Page 26: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Isolation = Fondamental

Rend le test véritablement unitaire

Automatisation avec un framework de mocking (ex : Moq)

Simuler des dépendances

SUT

Dépendance

Doublure

Interface

On simule l’implémentation attendue

=

Page 27: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Code écrit par Kévin remasterisé

Page 28: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

DRY – Don’t Repeat Yourself

« Dans un système, toute connaissance doit avoir une représentation unique, non-ambiguë, faisant autorité. »

- Andy Hunt et Dave Thomas (The Pragmatic Programmer)

Page 29: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Composition over inheritance

• « Is a » VS « Has a »

• Meilleure testabilité

• Casse l’encapsulation

• Nécessaire pour l’application de certains patterns

Page 30: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Code Smells (« Odeurs du code »)

• Méthodes longues / Grosses classes

• Longue liste de paramètres

• Utilisation de switch

• GOTO / Codes de retour d’erreur

• Noms de méthodes avec ET/OU

• Code dupliqué

• Code mort

• Navigation transitive

• Nombres magiques

• Généralité spéculative

• Commentaires

• Séparation verticale

• Chirurgie avec fusil à pompe

• Héritage parallèle

Page 31: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Repérer les Code Smells

• Relecture de code

-> Pair Programming

-> « Clean Code Cheat Sheet » de Urs Enzler

• Analyse statique de code

-> Repère des erreurs de conception / programmation

-> Outils : FxCop, StyleCop, Resharper, NDepend

Page 32: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Pour aller plus loin…

Page 33: [Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?

Merci !