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