Test Driven Development (TDD)

Présentation au sujet: "Test Driven Development (TDD)"— Transcription de la présentation:

1 Test Driven Development (TDD)
Formation Envol 2016 Bruno MERMET Novembre 2016

2 Déroulement de la session
Cours Pourquoi le TDD Premier exemple Refactoring Étude de cas Travaux Pratiques Mise en œuvre en binômes Pour conclure Retour d'expérience Prolongement (ATTD, BDD)

3 TDD Kesako ? Définition : TDD = Test Driven Development
Développement Guidé par les Tests Les tests précèdent le développement Conséquences On n'écrit du code que pour répondre à un nouveau cas de test On va au plus simple On a automatiquement un taux de couverture de 100 %

4 TDD Pourquoi ? Développement habituel Tests reportés à la fin Bâclés
Temps de correction pas pris en compte En cas de tests « boîte blanche » : Tests biaisés, car faits complètement par rapport au code En cas de tests « boîte noire » : Travail d'analyse fait 2 fois Choix de conception pré-déterminés Peuvent se révélés inadaptés au bout d'un certain temps Peuvent prendre en compte des cas qui ne se présenteront jamais Adapté au développement itératif Permet d'assurer facilement la non-régression

5 Les Origines (1) Manifeste Agile (2001)
Manifeste pour le développement de logiciel Agile Nous découvrons de meilleures façons de développer des logiciels en le faisant et en aidant les autres à le faire. Grâce à ce travail, nous avons été amenés à privilégier : Les individus et les interactions aux processus et outils ; Les logiciels qui fonctionnent à une documentation exhaustive ; La collaboration avec le client à la négociation de contrat ; La réactivité aux changements au respect d'une planification. C'est pourquoi, même si les critères "à droite" ont leurs intérêts, nous privilégions les critères "à gauche".

6 Les origines (2) Manifeste pour l'Artisanat du Logiciel (2009)
En tant qu'aspirants "artisans logiciels", nous relevons la barre du développement de logiciel professionnel, en le pratiquant et en aidant les autres à apprendre le métier. Grâce à ce travail, nous avons été amenés à privilégier : Pas seulement des logiciels qui marchent, mais des logiciels bien conçus ; Pas seulement de la réactivité aux changements, mais un ajout régulier de valeur ; Pas seulement des individus et des interactions, mais aussi une communauté de professionnels ; Pas seulement une collaboration avec le client, mais aussi des partenariats productifs. Ainsi, dans la continuité des items "à gauche", nous avons été amenés à considérer les items "à droite" comme indispensables.

7 Agile & Artisanat Processus & outils Individus et Interactions
Communauté de pro Documentation exhaustive Logiciels qui fonctionnent Logiciels bien conçus Négociation de contrats Collaboration avec le client Partenariats productifs Respect d'une planification Réactivité aux changements Ajout régulier de valeurs

8 Principes du TDD Première approche
Concevoir un cas de test i Concevoir un cas de test Développer le code sensé répondre au cas de test i Développer le code sensé répondre au cas de test oui Légende Au moins un test échoue Le test échoue Exécuter le test Exécuter tous les tests Corriger le code Tous les tests réussissent Le test réussit Cas d'utilisation non testés ? non

9 Exemple Écrire un programme qui calcule la somme de 2 entiers
Cas de test Données : A = 3 B = 4 Résultat Attendu R = 7 Code public int somme(int a, int b) { return 7 ; }

10 Outils pratiques pour la mise en œuvre (1)
Junit (3, 4, 5?) pour écrire les tests (cours Junit) Maven/IDE pour exécuter les tests (cours Maven)

11 Junit 4 Présentation en 1 transparent
Les tests sont écrits en Java, dans des classes dédiées (dans un répertoire de sources différent, mais font partie de l'application) Une méthode de test est une méthode de la forme : @Test public void nomMethode() {…} Une méthode de test : Lève une AssertionError pour un test raté Ne fait rien de particulier pour un test réussi Les méthodes de classe de org.junit.Assert sont très pratiques, notamment : assertEquals(Type résultatAttendu, Type résultatEffectif)

12 Junit 4 Retour sur l'exemple
import org.junit.Test ; import static org.junit.Assert.* ; public class ArithmetiqueTest { @Test public void testSomme1() { // données d'entrée int a = 3 ; int b = 4 ; // résultat attendu int resultatAttendu = 7 ; // résultat effectif int resultatEffectif = Arithmetique.somme(3,4) ; // vérification assertEquals(resultatAttendu, resultatEffectif) ; }

13 Étude de cas 1 1ère partie Cahier des charges
Écrire un programme qui, en fonction de 3 données saisies par l'utilisateur et supposées être des entiers (inférieurs strictement à 231) décrivant les longueurs des côtés d'un triangle, précise si le triangle est équilatéral, isocèle ou scalène*. Travail Faire le travail demandé en utilisant le TDD * scalène : triangle ni équilatéral ni isocèle

14 Étude de cas Bilan à mi-parcours
Bien que ce soit indispensable, ça peut devenir fastidieux de lancer systématiquement les tests Le code devient rapidement illisible, mal structuré, non maintenable => Nécessité de pratiquer du refactoring systématique

15 Outils pratiques pour la mise en œuvre (2)
Infinitest pour lancer les tests automatiquement, en continu

16 Refactoring Définition
Modification de la structure d'un code sans en changer la sémantique Dans le cas du TDD Fait progressivement, donc assez facile Fait en fonction des besoins, donc forcément adapté Les cas de tests déjà écrits permettent sa validation en assurant la garantie de la non-régression => nécessite moins de temps de cerveau

17 Principes du TDD Légende Concevoir un cas de test i
Tous les tests réussissent Au moins un test échoue Concevoir un cas de test i Développer le code sensé répondre au cas de test oui incorrecte Refactorer oui Refactorisation possible ? Exécuter tous les tests Corriger le code non Vérifier couverture des tests Cas d'utilisation non testés ? correcte non

18 Guides pour le refactoring

19 Refactoring esthétique
Revoir les indentations Uniformiser les espaces Uniformiser les accolades Pas de bloc sans accolade Positions unifiées Rapprocher déclarations et utilisations Regrouper et ordonner les déclarations

20 Refactoring structurel divers
Envie de fonctionnalité Méthodes statiques inappropriées Dépendances logiques non imposées

21 Refactoring documentaire
Revoir les noms Méthodes Variables Classes Packages Mettre à jour la javadoc Mettre à jour les éventuels commentaires Encapsuler les expressions non conditionnelles dans des méthodes Décomposer les grosses expressions

22 Refactoring de consistance
Supprimer code mort et méthodes mortes Introduire constantes et types énumérés autant que possible Externaliser les ressources si nécessaire Introduire des méthodes si plusieurs morceaux de code identiques Introduire des classes « intermédiaires » si parties communes entre les classes Uniformer les « niveaux » de traitement

23 Refactoring simplificateur
Limiter le nombre de lignes par méthode Limiter le nombre de méthodes par classe Limiter le nombre de paramètres dans les méthodes Réduire le nombre de boucles et de tests imbriqués Supprimer les « if (… != null) {… } » 1 méthode = 1 rôle

24 Refactoring lié aux tests
Profils de méthodes modifiés Méthodes ajoutées Couverture de code incomplète

25 Outils pratiques pour la mise en œuvre (3)
Checkstyle (Findbugs, PMD) pour souligner des risques de problèmes dans le code (Support checkstyle) STAN (STructure ANalysis for Java) EclEmma pour vérifier la couverture du code

26 Étude de cas 2 Calcul de la distance entre 2 points

27 TP Calculatrice en RPN Présentation
Certaines calculatrices fonctionnent en Notation Polonaise Inversée (RPN), autrement dit en « notation postfixe ». L'utilisateur peut : Entrer un nombre : il est empiler Entrer un opérateur : les opérandes sont dépilés, l'opération est effectuée, puis le résultat est empilé Exemple pour calculer (2+3)*(5-6) 2 ¿ 3 ¿ + ¿ 5 ¿ 6 ¿ - ¿ * ¿ Travail demandé Développer en TDD une classe simulant le fonctionnement d'une calculatrice RPN et proposant les opérations suivantes : 4 opérations : +, -, *, / Carré, racine carré : ^, sqrt Factorielle Cette classe doit pouvoir prendre les différentes opérations aussi bien de manière unitaire que via une chaîne de caractères (les espaces sont alors utilisés pour séparer les différentes entrées)

28 Retour d'expérience

29 Pour aller plus loin ATDD & BDD
Acceptance Test Driven Development Exemple avec FitNesse Behaviour Driven Development Cucumber GIVEN WHEN THEN