Le développement piloté par les Le développement piloté par les teststests

Laurent CARON – lcaron@interfaces-solutions.fr

1

A l’école on m’a appris…

2

LE CYCLE EN V…

Exigences

Analyse Tests d’intégration

Tests fonctionnels

3

Implémentation

Conception Tests unitaires

mar avr mai jui juil aou sep oct nov dec jan

ET CA FONCTIONNE ?

�Bien sûr, si on a des spécifications impeccables, limpides et lisibles…

4

ET CA FONCTIONNE ?

�Par un client qui sait ce qui veut…

5

ET CA FONCTIONNE ?

�Et une équipe de développeurs en béton qui respectent les délais

6

ET DANS LA VRAIE VIE ?

� Les spécifications arrivent en retard…

�Sont retouchées…

� Le développement a été refait 18 fois !

�Pour tenir à peu près les délais, on rogne un peu sur les tests…un peu sur les tests…

�Puis beaucoup…

�On recette sur une version bêta

�Puis on croise les doigts à chaque livraison

7

DEVELOPMENT HELL

Augmentation de la pression

Baisse de la

8

Baisse de la productivité

Code moins stable

Moins de temps pourécrire les tests

EN PLUS…

�Ce n’est la faute de personne

Expression des besoins

Spécifications

9

Codage

Tests

Cahier de testsBUG !

EN PLUS…

�Ce n’est la faute de personne

Expression des besoins

Spécifications

C’est leur faute !

10

Codage

Tests

Cahier de tests

EN PLUS…

�Ce n’est la faute de personne

Expression des besoins

Spécifications

C’est mal spécifié !

11

Codage

Tests

Cahier de tests

EN PLUS…

�Si, c’est celle du client !

Expression des besoins

Spécifications

C’est mal exprimé !

12

Codage

Tests

Cahier de tests

Voici le règne des avenants !

UNE SEULE SOLUTION

13

Et pourquoi pas autre chose ?

14

LE DÉVELOPPEMENT PILOTÉ PAR LES TESTS

�On écrit les tests AVANT le code

�Déroulement :

� Ecriture du test

� Vérification de l'échec du test (puisque le code n'existe pas encore)n'existe pas encore)

� Ecriture du code

� Vérification du test

� Refactoring (amélioration en gardant les mêmes fonctionnalités) : javadoc, commentaires…

15

Codage du test

CompilationRefactor

LE DÉVELOPPEMENT PILOTÉ PAR LES TESTS

Correction des erreurs de compilation

Lancement du testéchec

Ecriture du code

Lancement du testJusqu’à ce qu’il passe

16

INTÉRÊT

� Précisent les spécifications

� Force à réfléchir très tôt aux jeux de test

� Permet d'arrêter le travail au bon moment (quand les tests passent)

�Par conséquent, la conception est �Par conséquent, la conception est meilleure

17

INTÉRÊT

� Le code produit est testable

� Test de composants en couche sans avoir besoin des couches de présentation

� Automatisation et non-régression

� Refactoring aisé

� Confiance dans le code� Confiance dans le code

18

Ce n’est pas seulement une technique…

19

DANS LES PROJETS INFORMATIQUES…

�On rencontre principalement 3 types d'intervenants

� Ceux qui « spécifient »

� Ceux qui « codent »

� Ceux qui « testent »� Ceux qui « testent »

�Mais, la plupart du temps…

� Ils ne parlent pas le même langage

� Ils ne travaillent pas ensemble

� Ils ne se connaissent parfois même pas

20

QUE FAIRE ?

� Il faut les aider…

� à travailler ensemble

� à rendre le travail de chacun utile

� à se sentir ensemble dans cette aventure

21

QUE FAIRE ?

�Spécifier les comportements avec des exemples

� Lier les spécifications au code de production

�Ecrire des tests avant le code�Ecrire des tests avant le code

�Echanger des idées en écrivant des tests

�Partager un résultat attendu avant de coder

22

QUE FAIRE ?

�Faire des tests les vedettes de votre projet

�Se mettre d'accord sur ce que l'on veut puis coder

�Capitaliser les conversations dans des tests

Documenter l'utilisation d'un code dans �Documenter l'utilisation d'un code dans des tests

23

BONNES PRATIQUES

� Tests Petits

� Tests Isolés

� Fonctionnant sous n'importe quel environnement

� Tests Complets

� Tests Répétables� Tests Répétables

� Tests Automatiques

� Tests Clairs pour tout le monde

� Concevoir les tests comme des spécifications, pas comme des vérifications

24

Et comment faire avec du code existant ?

25

LE CODE EXISTANT…

� Il n’y a pas de test

� Ce code n’a pas été conçu pour qu’on puisse écrire simplement des tests

� Par où je commence ?

26

ON ÉCRIT LE TEST POUR TOUT LE CODE ?

� Le projet est gros, il faut donc passer les 6 prochains mois à écrire des tests

� Evidemment, ce n’est pas réaliste !

� Commençons petit !

27

ON COMMENCE PAR 1 TEST !

� Cherchez une portion de code testable (classe, méthode, fonction…)

� Ecrivez un test qui porte sur cette portion

� Lancez-le : il doit réussir

� (enfin, normalement ☺)� (enfin, normalement ☺)

� Ecrivez un test par jour…

28

TESTEZ À CHAQUE MODIFICATION DU CODE

� La prochaine fois que vous devez corriger un bug, écrivez un test qui permet de reproduire ce problème…

�Et qui échoue !

�Si la portion de code n’est pas testable, �Si la portion de code n’est pas testable, modifier le code pour l’isoler et la tester !

29

LANCEZ VOS TESTS !

�Quand vous avez écrit vos tests, vous devez les lancer !

�Si vous ne le faites pas, ils sont inutiles…

�Et c’est mieux si vous les faites exécuter automatiquement…automatiquement…

30

LES DÉFAUTS DE L’APPROCHE TDD

�Coûteux en temps

�Parfois complexe à concevoir

�Peut sembler peu utile car le développeur doit car le développeur doit envisager tous les cas de figure, même ceux a

priori inutiles

31