Développement dirigé par les tests : mise en pratique


précédentsommairesuivant

I. Introduction

I-A. Un peu d'histoire

Il y a quelques temps, je travaillais pour une société informatique où se tenaient certaines conversations entre développeurs, chefs de projet et décideurs sur le test d'application. Certains d'entre eux disaient que les tests unitaires automatisés c'est rébarbatif, une perte de temps et que des tests fonctionnels effectués manuellement par un personnel adéquat suffisent amplement. Bien sûr, chaque livraison était accompagnée de son lot de bugs de régression, de non-conformité au besoin, etc. En conséquence de cela, venait une phase de correction bien stressante et les testeurs chargés de relancer leurs tests manuels (vous savez, une bonne feuille Excel qui indique chaque étape à effectuer) n'en pouvaient plus. Ce genre de cycle de développement, je l'ai vécu 2 ans. Lorsque le client a haussé le ton sur la qualité de l'application livrée, les décideurs ont réagi sur le coup en demandant aux " testeurs " d'appréhender une plateforme de tests automatisés et d'écrire les tests. Concernant les développeurs, ils étaient invités à faire des heures supplémentaires pour écrire des tests unitaires. Selon moi, c'était trop tard. L'application était déjà trop grosse pour pouvoir couvrir tous les cas d'utilisation et leurs règles de gestion sachant que la fin du projet arrivait très vite.

I-B. Objectifs

Les objectifs de ce tutoriel sont d'une part de présenter et appliquer certains principes de la méthodologie XP, notamment le Développement piloté par les tests (Test Driven Development) et le remaniement d'application (Refactoring). Nous tenterons de montrer que les tests unitaires permettent :

  • De contrôler et conserver la qualité du produit tout au long du projet
  • De se focaliser sur l'amélioration du code, plutôt que sur les bugs
  • D'améliorer la productivité de l'équipe en automatisant un maximum de tâches redondantes et ennuyantes

D'autre part, nous montrerons que l'apprentissage et maturité sur l'application viennent au fur et à mesure de son cycle de développement. L'effort sera assez conséquent lors des premières tâches ("mavenisation" du projet, intégration des frameworks applicatifs et de test) mais il se réduira pour atteindre un niveau acceptable dans le sens où il ne sera soutenu que dans l'implémentation fonctionnelle des besoins.

I-C. Pré-requis

I-D. Cahier des charges

Système de gestion de notes avec comme fonctions attendues :

  • Authentification avec la notion d'administrateur et d'utilisateur normal
  • Rôle utilisateur normal : Modification du profil et liste, ajout modification et suppression de notes
  • Rôle administrateur : fonctions de liste, ajout, mise à jour et suppression des utilisateurs et de ses notes

I-E. Modèle de données

Image non disponible
Modèle de données

I-F. Architecture de l'application et choix des frameworks

Nous suivrons un standard d'architecture des applications Web. L'application sera décomposée comme ci-dessous :

  • Une couche DAO implémentée avec iBatis ;
  • Une couche métier ;
  • Une couche web implémentée avec Wicket ;
  • L'ensemble sera configuré via Spring ;
  • Le container de servlet sera Jetty ;
  • La base de données sera Hsqldb ;
  • La version du langage java sera 5 (Tiger) ;
  • La structure du projet suivra le standard Maven 2.

Ce tutoriel n'a pas vocation à explorer les frameworks cités ci-dessus, ils servent seulement d'illustration. Néanmoins ci-dessous quelques arguments sur le choix :

  • iBatis : La mise en oeuvre est très simple et j'apprécie la séparation entre le code SQL et le code Java. Il n'est pas aussi puissant qu'Hibernate mais ses possibilités suffisent amplement à illustrer ce tutoriel ;
  • Spring : Il est inutile de répéter ce qu'apportent l'Inversion de contrôle et l'injection de dépendance. Il existe suffisamment d'articles à ce sujet ;) ;
  • Wicket : J'aime bien son approche très "java centric" et orientée composants à la manière de Swing (phase de remaniement plus aisé), il respecte bien le modèle MVC et il se passe des JSP ;
  • Hsqldb : Base de données embarquée qui peut d'exécuter en mode mémoire ce qui est très pratique pour les tests unitaires ;
  • Jetty : Container de Servlet très compact qui nous permettra de faire des tests fonctionnels de l'application sans devoir configurer un environnement de recette ou de production.

Nous évoquerons les frameworks de test tout au long de ce tutoriel.

I-G. Organisation

La méthode XP préconise le découpage des besoins en scénarii qui seront composés de plusieurs tâches. Ainsi, en se fixant des objectifs sur du court terme, on a l'impression d'avancer rapidement. Nous allons donc organiser les scénarii de cette application en chapitres:

  • Chapitre 1 : Création du projet;
  • Chapitre 2 : Gestion de l'authentification;
  • Chapitre 3 : Tests fonctionnels;
  • Chapitre 4 : Gestion de notes;
  • Chapitre 5 : Gestion des utilisateurs.

Pour chacun (hors chapitres 1 et 3) les tâches seront les suivantes :

  • Tâche 1 : écriture de la couche DAO;
  • Tâche 2 : écriture de la couche Métier;
  • Tâche 3 : écriture de la couche WEB.

précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2009 David Boissier. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.