by Laurent Caron

1. Le développement piloté par les
tests
Laurent CARON – lcaron@interfaces-solutions.fr
1

2. A l’école on m’a appris…
2

3. LE CYCLE EN V…
Exigences Tests fonctionnels
Analyse Tests d’intégration
Conception Tests unitaires
Implémentation
mar avr mai jui juil aou sep oct nov dec jan
3

4. ET CA FONCTIONNE ?
Bien sûr, si on a des spécifications
impeccables, limpides et lisibles…
4

5. ET CA FONCTIONNE ?
Par un client qui sait ce qui veut…
5

6. ET CA FONCTIONNE ?
Et une équipe de développeurs en béton
qui respectent les délais
6

7. 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…
Puis beaucoup…
On recette sur une version bêta
Puis on croise les doigts à chaque livraison
7

8. DEVELOPMENT HELL
Augmentation
de la pression
Baisse de la Moins de temps pour
productivité écrire les tests
Code moins
stable
8

9. EN PLUS…
Ce n’est la faute de personne
Expression des besoins
Spécifications
Codage
Cahier de tests
BUG !
Tests
9

10. EN PLUS…
Ce n’est la faute de personne
Expression des besoins
Spécifications
C’est leur faute !
Codage
Cahier de tests
Tests
10

11. EN PLUS…
Ce n’est la faute de personne
Expression des besoins
C’est mal spécifié !
Spécifications
Codage
Cahier de tests
Tests
11

12. EN PLUS…
Si, c’est celle du client !
Expression des besoins
C’est mal exprimé !
Spécifications
Codage
Cahier de tests
Voici le règne des avenants !
Tests
12

13. UNE SEULE SOLUTION
13

14. Et pourquoi pas autre chose ?
14

15. 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)
Ecriture du code
Vérification du test
Refactoring (amélioration en gardant les
mêmes fonctionnalités) : javadoc,
commentaires…
15

16. LE DÉVELOPPEMENT PILOTÉ PAR LES TESTS
Codage du test
Refactor Compilation
Lancement du test Correction des
Jusqu’à ce qu’il passe erreurs de compilation
Lancement du test
Ecriture du code
échec
16

17. 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
meilleure
17

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

19. Ce n’est pas seulement une
technique…
19

20. DANS LES PROJETS INFORMATIQUES…
On rencontre principalement 3 types
d'intervenants
Ceux qui « spécifient »
Ceux qui « codent »
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

21. QUE FAIRE ?
Il faut les aider…
à travailler ensemble
à rendre le travail de chacun utile
à se sentir ensemble dans cette aventure
21

22. QUE FAIRE ?
Spécifier les comportements avec des
exemples
Lier les spécifications au code de
production
Ecrire des tests avant le code
Echanger des idées en écrivant des tests
Partager un résultat attendu avant de
coder
22

23. 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
des tests
23

24. BONNES PRATIQUES
Tests Petits
Tests Isolés
Fonctionnant sous n'importe quel environnement
Tests Complets
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

25. Et comment faire avec du code
existant ?
25

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

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

28. 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 ☺)
Ecrivez un test par jour…
28

29. 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,
modifier le code pour l’isoler et la tester !
29

30. 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…
30

31. LES DÉFAUTS DE L’APPROCHE TDD
Coûteux en temps
Parfois complexe à
concevoir
Peut sembler peu utile
car le développeur doit
envisager tous les cas de
figure, même ceux a
priori inutiles
31