BEST

Qualité des développements avec Test Driven Development

Optimiser son développement logiciel par les tests

Description

Pratique de base des équipes Agiles, le développement dirigé par les tests (TDD : Test Driven Development) est une technique de programmation simple, élégante et efficace, qui repose sur un cycle de feedback court : écrire un test – le faire passer – refactorer le code. Cette approche allie l’avantage d’une conception modulaire et lisible, à la sécurité que procure la couverture du code par les tests automatisés. A l’issue de cette formation, vous serez ainsi en mesure d’écrire des applications entières, étayées par du code en état de marche, particulièrement maintenables et évolutives.

Objectifs pédagogiques

  • Identifier les avantages de TDD sur les autres techniques de programmation (code puis T.U)
  • Développer une application simple avec TDD
  • Expliquer et illustrer les principes à l’œuvre dans cette démarche
  • Utiliser TDD sur un projet nouveau
  • Utiliser des techniques spécifiques de TDD sur un projet existant

Public cible

  • Chef de projet en développement
  • Développeur
  • Testeur ayant une fibre développement
  • Architecte
  • Technical Leader

Pré-requis

  • Connaissances de la programmation objet.
  • Expérience de base du développement de logiciel.

Méthode pédagogique

Formation pratique, visant à l’acquisition d’un savoir-faire, basée sur des exercices pratiques ainsi que des échanges et retours d’expérience pratique du formateur.

PROFILS DES INTERVENANTS

Toutes nos formations sont animées par des consultants-formateurs expérimentés et reconnus par leurs pairs.

MODALITÉS D'ÉVALUATION ET FORMALISATION À L'ISSUE DE LA FORMATION

L'évaluation des acquis se fait tout au long de la session au travers des ateliers et des mises en pratique. Une évaluation à chaud sur la satisfaction des stagiaires est réalisée systématiquement en fin de session et une attestation de formation est délivrée aux participants mentionnant les objectifs de la formation, la nature, le programme et la durée de l'action de formation ainsi que la formalisation des acquis.

Programme :

Jour 1

  • Connexion
    • Tour de table
      • Présentation des participants
      • Brainstorming : les pratiques de développement utilisées en entreprise
      • Les pièges à éviter lorsque l’on programme
  • Perception du TDD
    • Mythes du TDD
    • Réalité du TDD
    • Exercices pratiques
      • Tester unitairement produit
      • Concevoir un produit via les tests unitaires
  • Gestion des exceptions - Refactoring
  • Définir un test
    • En génie logiciel
    • En TDD
    • Exercice pratique : compréhension d’un code de tests
  • Définir le Test Driven Development
    • Mettre en évidence l’intention
    • Réfléchir avant chaque ligne de code
    • Bénéfice de la couverture de tests
  • Feedback et Agilité
    • Notions de base
    • Exercice pratique : identifier tous les feedbacks que peut utiliser un développeur
    • Brève histoire du feedback entre le développeur et son code
    • Importance du feedback
    • Le coût croissant de correction des défauts
    • Information vs feedback
    • Exercice pratique : échanges sur des situations analogues où le soin porté à l’outil favorise la vitesse de production
  • TDD et génie logiciel
    • Renversement du modèle industriel classique
    • Comparaison des modèles industriel et artisanal
    • Pratiques autour de la sphère TDD
    • Points d’attention
    • Obstacles à l’adoption de TDD
  • Bases de TDD : développement d’une application simple
    • Présentation générale
    • Exercice pratique : conception par carte responsabilités / collaboration
    • Pattern TDD : test list
    • Exercice pratique : lister les tests d’une des classes du projet
    • Le cycle de TDD
    • Des règles simples
    • Pattern : Assert First
    • Exercice pratique : mettre en route son environnement et écrire un premier test
  • Trois patterns caractéristiques de TDD
    • Pattern TDD : "Fake it ‘til you make it"
    • Pattern TDD : "Triangulate"
    • Pattern TDD : "Obvious Implementation"
    • Exercice pratique : manipuler ces 3 patterns sur une fonction simple
    • Pattern TDD : "Données de test"
    • Pattern TDD : "Tests isolés"
    • Exercice pratique : développement d’une classe simple (conteneur)
    • Exercice pratique : développement d’une classe dotée de logique (règles métier)
    • Exercice pratique : développement d’une collaboration entre 2 classes (application)
  • Clôture du jour 1

Jour 2

  • Connexion
    • Partager avec le groupe sa session de programmation / débogage la plus difficile
  • Principes de survie TDD
    • Pattern TDD : "Don’t Repeat Yourself"
    • Pattern TDD : "You Ain’t Gonna Need It"
    • Problème des dépendances extérieures
    • Pattern TDD : "Stub"
    • Exercice pratique : créer un Stub pour résoudre un problème de données de tests
    • Pattern TDD : "Mock"
    • Exercice pratique : créer un Mock pour simuler un appel de méthode
  • Développement d’une application (suite)
    • Exercice pratique :
      • Développement d’une collaboration entre plusieurs classes (cycle de vie de l’application)
      • Développement d’une classe dépendante aux effets de bords (ex. : horloge système)
      • Développement d’une collaboration entre plusieurs classes (sessions multiples)
      • Développement d’une application connectée (serveur)
      • Développement d’une application connectée (client)
  • Clôture du jour 2

Jour 3

  • Connexion
    • Partage d’expériences sur le code existant
  • Antipatterns TDD
    • Antipattern TDD : "Succès inattendu d’un test"
      • Exercice pratique : analyse critique d’un test qui passe du premier coup
    • Antipattern TDD : "Ecrire des tests trop grands"
      • Exercice pratique : analyse critique d’un test trop grand
    • Antipattern TDD : "Diagnostic trop long"
      • Exercice pratique : analyse critique d’un test donnant lieu à un diagnostic long
    • Antipattern TDD : "Test sur une méthode privée"
      • Exercice pratique : analyse critique d’un test d’une méthode privée
    • Antipattern TDD : "Echec intermittent"
      • Exercice pratique : analyse critique d’un test qui passe de façon intermittente
    • Concept et présentation du code legacy
  • Le problème du code Legacy
    • Modifier et préserver le code
    • Le paradoxe : refactorer du code sans tests pour y ajouter des tests
  • Amener du code sous tests
    • Identifier un point de changement
    • Trouver les points de test
    • Casser les dépendances
    • Créer un raccord (seam)
    • Modifier le code et refactorer
    • Exercice pratique : écrire des tests sur un code existant en vue de documenter le code
    • Exercice pratique : écrire des tests permettant de refactorer le code
  • Synthèse et rappel des points clés de la formation

Pour aller plus loin :

Type : Stage pratique en présentiel
Code formation : TDD01
Durée : 3 jours (21 heures)

Sessions inter-entreprises :

Tarif & dates intra-entreprise :
Devis sur demande
Nous Contacter