[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

Qui suis-je ?

• Consultant .NET à Bordeaux

• Agiliste

Et surtout :

• Artisan logiciel

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.

Code existant

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

Fortement couplé / trop de responsabilités

Sans tests -> Difficilement testable

Architecture classique en couches

Les choses à ne pas faire : STUPID

Singleton

Tight Coupling

Untestable

Premature Optimization

Indescriptive Naming

Duplication

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

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

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)

SRP - Single Responsability Principle(Responsabilité unique)

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

- Robert C. Martin

SRP - Avant

SRP - Après

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

OCP – Avant

OCP – Après

LSP – Liskov Substitution Principle(Substitution de Liskov)

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

LSP – Avant

LSP – Après

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.

ISP – Avant

ISP – Après

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

DIP – Avant

DIP – Après

SOLID en 5 images

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 !

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

=

Code écrit par Kévin remasterisé

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)

Composition over inheritance

• « Is a » VS « Has a »

• Meilleure testabilité

• Casse l’encapsulation

• Nécessaire pour l’application de certains patterns

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

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

Pour aller plus loin…

Merci !