TDD - Le développement piloté par les tests

Les tests fonctionnels avec TDD

Spécifications exécutables

Dans un projet informatique, il n'est pas impossible que des erreurs d'interprétation de règles fonctionnels d'un cahier des charges surviennent. Dans ce cas présent, le besoin du client aura mal été pris en compte et cela risque de provoquer une perte de temps.

Afin d'éviter ce genre de problème, il est impératif d'impliquer le client dés le début du développement et lui permettre de contrôler et valider lui même les règles fonctionnelles. Pour ce faire, il doit fournir aux développeurs un ensemble de scénarios clients où sont décrits des régles fonctionnelles et ainsi supprimer toutes les ambigüités ou erreurs d'interprétations.
Pour faciliter la rédaction de ces scénarios client par les clients, un Wiki sera mis à leur disposition et ils pourront à leurs aises écrire des scénarios clients avec les moins de difficultés possibles.

Cette approche demande de mettre en place une couche logicielle (appelé Fixture) permettant de faire le pont entre les pages de tests et les services de l'application testée.

Voici un schéma d'un outil de spécifications exécutables qui décrit les différentes entités avec leurs relations de cette nouvelle approche :

Il s'agit ici de l'organisation de l'outil FitNesse, la couche FIT(Fixtures) correspond au pont et permet de court circuiter l'IHM et ainsi de tester uniquement les règles fonctionnelles.

Les outils tels que FitNesse et GreenPepper offrent le moyen de mettre en œuvre cette méthode.

Description des spécifications exécutables avec l'outil FitNess

Fitness est composé d’un wiki qui référence les scénarios de tests, d’un moteur d’exécution pour extraire les données des tests et enfin de codes de liaison pour mettre en corrélation ces données avec le code applicatif (écrit en C#, Java ou C++).
L’édition et l’exécution des scénarios de tests se font via le wiki intégré. L’édition, peut se faire en mode déconnecté avec un éditeur de texte (Excel, Word, Notepad,…). Les scénarios seront ensuite importés dans le wiki. FitNesse met donc l’élaboration, la documentation et l’exécution de ces scénarios à la portée de tous.
La corrélation entre les données de test et le code applicatif se fait par l’intermédiaire d’APIs écrites par le développeur. Pour l’aider dans son développement, FIT intègre lui aussi une API contenant un certain nombre de Fixtures.

Voici certains Fixtures offerts par FitNesse :

• ColumnFixture :
  Permet d'accéder au modèle métier de l’application. Il est par exemple possible d'initialiser des objets métier qui seront utilisés par la suite
• RowFixture :
  Permet de vérifier le contenu exact d’une liste
• ActionFixture :
  Permet de simuler les actions d’un utilisateur

Voici un tableau d'un Wiki représentant un ensemble de règle fonctionnelle pour un scénario :

Le tableau est composé de 3 groupes de ligne :

• La première ligne du tableau indique le titre du scénario, en l'occurrence il s'agit ici d'un scénario dont le but est de contrôler le déroulement de l'achat de n'importe quel article. Il est aussi mentionné pour information que le prix par défaut d'un article est de 10 euros.
• La seconde ligne indique le nom des variables et méthodes utilisées pour définir les règles fonctionnelles.
• Les lignes suivantes indiquent chaque cas possibles pour ce scénario.

La terminologie et la simplicité du tableau font qu'il est très simple de comprendre les règles fonctionnelles.

BDD - Behavior Driven Developement

Le Behaviour Driven Development (BDD) est une méthode de développement agile visant à se baser sur le comportement de l'utilisateur pour créer son application.
Un test en BDD consiste à décrire une fonctionnalité selon un formalisme « Given / When / Then ».

Chaque mot clé a une signification bien précise :

• Given :
  La description, il permet généralement de décrire l'état initial
• When :
  L'action, il s'agit des actions éffectuées(appel d'une méthode,...)
• Then :
  La vérification, elle est présente pour vérifier que le résultat attendu(par exemple que le message affiché contient bien tel message

Il y a également les autres mots clés And et But qui reprennent le mot clé de la ligne précédente et ont donc pour but de clarifier le scénario

Il existe plusieurs outils permettant de mettre en œuvre la méthode BDD. On retrouve Cucumber(utilisation avec de nombreux langages), JBehave(uniquement en Java) ou encore NBehave (.NET).

Application de la méthode BDD avec JBehave

Voici la démarche à suivre pour créer un scénario :

• Créer un fichier représentant le scénario à travers le formalisme GIVEN/WHEN/THEN
• Le nom du fichier doit être uniquement composé de lettre minuscule et les mots doivent être séparés par un underscore(par exemple : user_logs_in_success)

Voici un exemple de fichier scénario :



Chaque phrase suivant les mots clés seront analysés et leurs actions seront traduits en code dans une classe Java.
Le nom de cette classe doit étendre la classe Scenario (propre à JBehave) et doit porter un nom correspondant au nom donné au fichier de scénario (écrit en CamelCase, par exemple user_logs_in_success devient UserLogsInSuccess).

Voici la classe du fichier scénario défini préalablement :

On remarque qu'une action précise est assoçiée à chaque mot clé.
En l'occurrence, une assertion ensureThat(currentPage, containsMessage(message)) est assoçiée pour le mot clé Then qui a pour but de vérifier le résultat attendu.
Les annotations en Java permettent d'apporter de la clarté et il devient simple de comprendre le scénario en lisant les quelques lignes de la classe.