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

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)

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 %

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

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

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.

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

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

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 ; }

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)

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)

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) ; }

É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

É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

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

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

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

Guides pour le refactoring

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

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

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

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

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

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

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

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

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)

Retour d'expérience

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