Date post: | 21-Jun-2015 |
Category: |
Technology |
Upload: | lyonjug |
View: | 337 times |
Download: | 2 times |
Le développement piloté par les Le développement piloté par les teststests
Laurent CARON – [email protected]
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