Médiathèque : tests unitaires, d'intégration et de validation

Préparation de votre environnement de travail

Dans cette étape, nous vous demandons de partir de l'archive proposée. En effet, le projet dans cette archive intègre des modifications présentées pendant le cours sur les tests.

Lors de cette étape, nous vous conseillons de suivre les diapositives du cours pour vous aider à répondre aux questions. Pensez à consulter les diapositives référencées dans ce sujet de TP.

• Récupérez le fichier Tests.zip dans votre espace de travail.
• Importez comme nouveau projet l'archive que vous venez de sauvegarder. Cela crée le projet Eclipse Test-osssature.
• Ce projet est configuré pour utiliser le canevas logiciel JUnit.
• Vous devez modifier le chemin de configuration du projet pour qu'il utilise la nouvelle version de l'archive util.jar que vous devez d'abord télécharger dans votre espace de travail.

Canevas logiciel JUnit et contenu de l'archive

Nous vous proposons dans ce TP d'utiliser le canevas logiciel (la librairie) JUnit pour écrire les tests. Ce canevas logiciel utilise les annotations Java.

Vous avez eu une introduction au canevas logiciel JUnit en cours. Lors du cours, vous ont été présentés des exemples de tests unitaires. Vous pouvez consulter ici la liste des modifications effectuées dans le code du projet MediaGraph pour intégrer ces tests unitaires.

Exécution des tests existants

Un certain nombre de tests présentés dans le cours ont été implantés. À titre d'exemple, ouvrez la classe JUnit_DocumentTest et parcourez rapidement les méthodes de test existantes. Exécutez les tests unitaires de cette classe dans Eclipse: dans le menu Run, choisissez Run as puis JUnit test ; cette action ouvre une perspective avec une barre verte, rouge ou bleue et des indicateurs montrant si les tests se sont déroulés correctement ou non.

En guise d'essai d'exécution en erreur d'un test, modifiez la méthode testReachableStates en retirant l'instruction d1.metEmpruntable(). Ré-exécutez la classe JUnit_DocumentTest et observez que le test correspondant « ne passe plus ».

Tests unitaires

À partir du cours, mettez à jour le fichier JUnit_DocumentTest.java du paquetage tests en ajoutant les tests qui manquent.

Vous devez ajouter les bonnes assertions pour chaque test et spécifier si besoin l'exception que doit générer le scénario du test (par exemple, comme dans l'annotation suivante « @Test(expected=OperationImpossible.class) »).

Voici les tests qui manquent :

1. « nombre d'emprunts » : emprunter un document 5 fois de suite (diapositive 45 du cours)  et vérifier que son nombre d'emprunts a évolué correctement ;
2. « test 4.1 » : vérifier qu'il n'est pas possible (une exception est levée) de restituer un document qui est empruntable mais non emprunté (diapositive 58 du cours) ;
3. « double emprunt »: vérifier qu'il n'est pas possible d'emprunter un document qui est déjà emprunté ;
4. « exception quand constructeur incorrect » : vérifier qu'une exception est levée quand le genre passé en argument est null dans le constructeur de la classe Document (diapositive 47 du cours).

Exécutez les tests unitaires dans Eclipse: dans le menu Run, choisissez Run as puis JUnit test ; cette action ouvre une perspective avec une barre verte, rouge ou bleue ainsi que des indicateurs montrant si les tests se sont déroulés correctement ou non.

Tests d'intégration avec Junit

Pendant le cours, une séquence a été proposée à la diapositive 30 concernant la coordination par la classe FicheEmprunt de l'interaction « emprunter », et ce conformément au corrigé du BE3-4 (regardez plus précisément les diagrammes de communications ou de séquence de l'opération emprunter). Ce test d'intégration est réalisé dans la classe IntegrationTest du paquetage tests de l'ossature fournie pour ce TP.

En vous inspirant des premiers tests d'intégration de la classe IntegrationTest, complétez la classe en écrivant les tests d'intégration pour l'interaction « restituer » qui testent l'enchaînement correct entre FicheEmprunt, Document et Client. Cette interaction est aussi décrite dans le corrigé du BE3-4. Voici les deux cas que nous vous proposons de tester :

1. l'emprunt est rendu à temps  :
   • création d'un document,
   • mise du document à empruntable,
   • création d'un client,
   • création d'une fiche d'emprunt,
   • restitution du document par l'appel à une méthode de la classe FicheEmprunt et vérification que la restitution est correcte du côté du document (le document peut être emprunté à nouveau) et du côté du client (le nombre d'emprunt en cours a diminué),
2. l'emprunt est rendu en retard :
   • la séquence est similaire à celle du test d'intégration précédent avec un appel à Datutil.addAuJour(...) pour avancer artificiellement l'horloge, un appel à la méthode verifier() de la classe FicheEmprunt pour tester si l'emprunt est en retard, et si verifier() a retourné la valeur true (c'est un emprunt en retard), un appel à la méthode premierRappel() pour marquer le client en retard.

Tests de validation

Pendant le cours, le fichier de tests de validation AcceptanceTest du paquetage src a été construit avec les deux premiers tests de la table de décision du cas d'utilisation « emprunter un document » présentée dans la diapositive 16 du cours.

1. Écrivez les tests de validation pour le cas d'utilisation « emprunter un document » pour au moins un des éléments de la table de décision (3-7) présentés mais non traités en cours. Commencez par les tests 4, 5 et 6, et terminez par les tests 7 puis 3, ce dernier étant de loin le plus long à réaliser. Pour la programmation de ces tests, notez que la méthode setUp crée de nombreux objets ; pensez à piocher dans cet ensemble pour écrire vos tests.
2. [Question optionnelle] Vérifier que la suppression d'un genre de la médiathèque ne peut être réalisée que lorsqu'aucun document ne référence ce genre,
   • Écrivez le test de validation correspondant.

Tests de toutes les classes dérivées de Document

Cet exercice est un peu plus compliqué car il utilise des concepts avancés comme les classes abstraites.

Les tests unitaires de la classe Document appliqués à un objet d'une classe enfant comme Vidéo exercent les méthodes factorisées dans la classe Document mais ne sont complets ni pour les méthodes redéfinies dans les classes enfants, ni pour les méthodes introduites dans les classes enfants. Par conséquent, dans cette dernière question, nous complétons les tests de la classe Document pour les classes dérivées. Pour cela, nous proposons les étapes suivantes :

1. rendez la classe JUnit_DocumentTest abstraite et supprimez la création de l'objet de type Vidéo de la méthode setUp. Cette classe n'est plus exécutable dans l'environnement JUnit. Changez la visibilité de l'attribut d1 pour que les futures classes enfants y accèdent ;
2. pour la classe Audio, créez une classe JUnit_AudioTest qui dérive de la classe JUnit_DocumentTest, et dans la méthode associée à l'initialisation par JUnit (méthode annotée @Before), créez un document de type Audio et utilisez l'attribut protégé d1 de la classe JUnit_DocumentTest pour référencer ce nouvel objet de type Audio ;
3. ainsi, vous pouvez passer l'ensemble des tests écrits pour la classe Document sur la classe Audio , excepté le test avec un genre à null;
4. modifiez les tests pour qu'ils fonctionnent avec Audio ;
5. ajoutez un test qui vérifie qu'une exception est levée lors de la construction d'un objet de type Audio avec une classification égale à null ;
6. faites de même avec les classes Livre et Video.

$Id: index.html 1544 2016-01-08 10:50:32Z conan $