tdd (test driven developement) et refactoring

TDD et Refactoring

Walid Skouri

Plan

• Introduction

• L’eXtreme Programming

• Les bases du TDD

• Les tests unitaires

• Le refactoring

2

Introduction

3

Introduction

• Introduction

• L’eXtreme Programming

• Les bases du TDD

• Le refactoring

4

Introduction

• Les démarches traditionnelles

– spécification > conception > réalisation > validation

– Concentre la plupart des décision au début d’un projet

– Les client réalisent que leurs besoins ont changé

5

Introduction

Accepter ce changment

• C’est une composante incontournable de tout projet

• Approche XP

6

eXtreme Programming

7

XP

L’idée

• Réduction significative de la durée du cycle de développement:

– Réduction du temps entre :

• L’implémentation d’une fonctionnalité

• Mise en production d’une nouvelle version du logiciel

8

XP

Comment• On ne fait de conception que pour les fonctionnalités

existantes, pas pour les fonctionnalités futures:

– On ne fait de généralisations dans la conception que lorsque des besoins concrets se font sentir.

– On n'introduit pas d'optimisations si elles ne sont pas demandées par le client.

• Priorité :

– Travail actuel bien fait : Code testé, simple, lisible et sans duplication

9

XP

Principaux éléments de fonctionnement de XP

• Cycles itératifs pilotés par le client : Le projet progresse au rythme d'itérations très courtes, dont le contenu fonctionnel est déterminé par le client.

• Travail d'équipe auto-organisé : L'équipe travaille réellement... en équipe. Les développeurs organisent eux-mêmes leur travail, interviennent sur l'ensemble du code, travaillent systématiquement en binômes, et synchronisent leurs développements plusieurs fois par jour.

• Programmation pilotée par les tests : les développeurs écrivent des test automatiques pour chaque portion de code qu'ils conçoivent, et ils s'appuient sur ces tests pour affiner et améliorer sans cesse la conception de l'application sans craindre de régression.

10

XP

Le coût des changements

11

Coût des changement

s

Temps

Traditionnel

XP

XP

Les valeurs de XP• Communication : XP favorise le contact humain, la communication directe, plutôt que le cloisonnement

des activités et les échanges de courriers électroniques ou de documents formels. Les développeurs travaillent directement avec la maîtrise d'ouvrage, les testeurs sont intégrés à l'équipe de développement, etc.

• Feedback : qu'il s'agisse d'itérations courtes, de livraisons fréquentes, de travail en binômes ou de tests automatiques exécutés en permanence, la plupart des pratiques XP sont conçues pour donner un maximum de feedback sur le déroulement du projet afin de corriger la trajectoire au plus tôt. En particulier, les points de début d'itération offrent à l'équipe le moyen de prendre du recul sur son fonctionnement et de l'améliorer sans cesse au fil des itérations.

• Simplicité : XP relève le défi suivant : « que pouvons-nous arrêter de faire tout en continuant à créer efficacement un logiciel qui réponde aux besoins réels du client ? ». Cette recherche de simplification touche le processus lui-même, mais aussi l'outil fabriqué (la mécanique de planification incite le client à focaliser les efforts sur les fonctions prioritaires) ou encore la conception de l'application (guidée par un principe de « You ain't gonna need it »).

12

Les bases du TDD

13

Les bases du TDD

Tests au début du développement

CommencerTests

échouésFini

Ecriture des tests

Ecriture du code

14

Les bases du TDD

Développements pilotés par les tests

Code propre

Tests échoués

Tous les tests

réussis

Refactoring

15

TDD

16

Les bases du TDD

• Ne jamais écrire de code sans avoir de tests qui échouent

• Les tests doivent être représentatifs des spécifications

17

Recommandations

Les test unitaires

18

Les tests unitaires

• Il permettent

– De contrôler et conserver la qualité du produit tout au long du projet

– De se focaliser sur l’amélioration du code, plutôt que sur les bugs

– D’améliorer la productivité de l’équipe en automatisant un maximum de tâches redondantes et ennuyantes

19

Les tests unitaires

• Privilégier la composition à l’héritage

• Isoler les dépendances

• Injecter les dépendances

20

Testabilité du code

Les tests unitaires

• Privilégier la composition à l’héritage

– L’héritage permet à la sous classe d’heriter toutes les fonctionnalité

– La composition permet une solution plus flexible et réutilisable

– Exemple: Permet d’instancier le l’objet composite avec différentes implémentations

Héritage Composition

class Fruit { //... } class Apple extends Fruit { //... }

class Fruit { //... } class Apple { private Fruit fruit = new Fruit(); //... }

21

Testabilité du code

Les tests unitaires

Injection de dépendance

• Se rapporte à la fourniture d'une dépendance externe à un composant logiciel.

• Formes d’injection de dépendance– interface injection

– setter injection

– constructor injection

22

Testabilité du code

Les tests unitaires

Injection du constructeurpublic class ImportantClass {

IFoo foo;

public ImportantClass()

{

this.foo = new EnterpriseFoo();

}

void doReallyImportantStuff() {

this.foo.bar();

}

}

public class ImportantClass {

IFoo foo;

public ImportantClass(IFoo foo) {

this.foo = foo;

}

void doReallyImportantStuff() {

this.foo.bar();

}

}

23

Testabilité du code

Refactoring

24

Refactoring

• C’est une technique de restructuration du code existant: modifier sa structure sans changer son comportement externe

• Ensemble de petites modifications dans le but d’améliorer le code

25

C’est quoi?

Refactoring

• Chaque transformation (ou Refactoring) ne modifie qu’une petite partie du code mais un ensemble de transformations peut produire un changement significatif

• Le système se doit de toujours fonctionner suite à chaque refactoring. Eviter les régressions.

26

C’est quoi?

Refactoring

• Améliorer la structure du logiciel

• Rendre le code plus lisible et maintenable

• Faciliter les futurs changements

• Plus de flexibilité

• Augmenter la réutilisabilité

• Faciliter la recherche de bugs

27

Pourquoi?

Refactoring

• Code dupliqué

• Longues méthodes

• Longues liste de paramètres

• Nommage inapproprié

28

Quand?

Démo

29