Contrôle Continu Pratique (CCP) d’entrainement

  • M1ALMA − Test Logiciel (XMS1IE301)

  • Contrôle Continu Pratique (CCP)

  • Date : XX/XX/20XX

  • Durée : 2 heures

1. Consignes

Le travail doit être réalisé sur les machines de TP de la salle informatique, et non à l’aide de vos machines personnelles.

Il est interdit de communiquer entre vous (ou avec quelqu’un d’extérieur), que ce soit dans la salle, ou par moyen numérique (échange de fichiers, messagerie instantanée, etc.).

Il est autorisé de demander de l’aide à l’enseignant, notamment pour vous dépanner en ce qui concerne l’usage des environnements de développement (IntelliJ), ou sur l’usage des outils demandés (en dernier recours). L’enseignant par contre n’est jamais obligé de vous répondre, notamment s’il estime que c’est à vous de connaître la réponse.

Vous n’avez accès que à certaines ressources numériques, qui incluent notamment le site web du cours, Madoc, et bien entendu Gitlab. Vous avez aussi normalement accès aux documentations des différents outils utilisés (JUnit, Mockito).

Une tentative d’outrepasser ces restrictions − pour accéder à des ressources en ligne non, pour s’aider d’une IA, pour communiquer avec une personne extérieure, etc. − pourra être sanctionnée. Dans le doute, demandez à l’enseignant.

Lorsque vous avez terminé :

  • Déclarez votre présence sur la page Madoc dédiée qui vous sera fournie.

  • Levez la main et signalez à l’enseignant que vous avez terminé, pour lui permettre de vérifier que le rendu est bien accessible.

2. Code étudié

Vous devez travailler sur le code d’une bibliothèque logicielle Java appelée Basic Planner, disponible sur le Gitlab de l’Université.

Cette bibliothèque fournit des concepts et opérations pour la mise en œuvre d’un agenda (planner) numérique simple. Il est possible de créer un agenda, d’y ajouter des réunions (meetings), tout en étant assuré que deux réunions ne soient jamais en conflit.

N’oubliez pas de lire le README de la bibliothèque.
Cette bibliothèque fait un usage important de l’API Java pour manipuler le temps et les durées, notamment via les classes Instant et Duration, de manière similaire à ce qui était déjà fait dans la bibliothèque train-reservation vue en TP.

3. Rendre votre travail

Votre travail devra être déposé sur Madoc à l’aide du lien qui vous sera fourni.

Vous devez rendre une archive compressée (en format .zip, .tar.gz ou équivalent) contenant l’intégralité du projet qu’il vous est demandé de tester, avec les modifications/ajouts que vous aurez réalisés (notamment vos scripts de tests).

Pour créer un .zip à partir de votre projet, vous pouvez utiliser cette commande :

$ zip -r mon_rendu.zip -r <répertoire>

où <répertoire> est le répertoire qui contient votre projet.

4. Travail demandé

Le barème est donné à titre indicatif et est susceptible de changer.

4.1. Exercice 1 − Développement de Tests Unitaire (~15 points)

On souhaite utiliser le framework JUnit pour implémenter un certain nombre de scénarios de test unitaires pour les classes MeetingImpl (spécifiée par l’interface Meeting) et BasicPlannerImpl (spécifiée par l’interface BasicPlanner).

Si vous pensez avoir découvert un défaut dans le code à l’aide de vos tests, décrivez-le dans un document à la racine de votre projet (defects.md par exemple), puis corrigez-le de manière à ce que vos tests passent.

Vous veillerez à appliquer les bonnes pratiques d’écriture de test vues en cours et en TP.
Les scénarios de test demandés sont volontairement décrits d’une manière incomplète, sans données d’entrée complètes et sans oracles complets. Vous devez par vous même proposer des données d’entrée suffisantes, et déterminer puis implémenter les oracles nécessaires.
N’oubliez pas d’exécuter vos tests au fur et à mesure de votre travail, pour vous assurer que votre configuration est bien correcte.

  1. Ajoutez JUnit (plus précisément, Jupiter) comme dépendance Maven au projet.

  2. Préparez une classe de test Exercice1Test dans laquelle vous implémenterez vos scénarios de test pour cet exercice.

  3. Implémentez les scénarios de test suivants pour le constructeur de la classe MeetingImpl :

    1. La valeur de startTime est null.

    2. La valeur de startTime est supérieure à la valeur de endTime.

    3. Le titre est une chaîne de caractères vide ("").

    4. Un meeting est créé avec succès.

  4. Implémentez les scénarios de test suivants pour la méthode addMeeting de la classe BasicPlannerImpl :

    1. Le nouveau meeting se termine pendant un meeting déjà existant dans l’agenda

    2. Le nouveau meeting débute pendant un meeting déjà existant dans l’agenda

    3. Le nouveau meeting est ajouté avec succès.

  5. Implémentez les scénarios de test suivants pour la méthode moveMeeting de la classe BasicPlannerImpl :

    1. On déplace un meeting null

    2. On déplace un meeting qui n’est pas déjà dans l’agenda

    3. On déplace un meeting en choisissant une nouvelle heure de début qui tombe pendant un meeting existant

    4. On déplace un meeting en choisissant une nouvelle heure de fin qui tombe pendant un meeting existant

4.2. Exercice 2 − Testabilité et doublures (~5 points)

On souhaite tester les deux méthodes seeCurrentMeeting et seeActiveReminders de la classe BasicPlannerImpl. Cependant, un problème de testabilité se présente et doit être résolu à l’aide de doublures.

Pour cette partie, vous êtes autorisés à effectuer toutes les modifications que vous trouvez nécessaires à la classe BasicPlannerImpl pour permettre l’utilisation de vos doublures. Tâchez bien entendu de garder ces modifications minimales.

  1. Ajoutez Mockito comme dépendance Maven au projet.

  2. Préparez une nouvelle classe de test Exercice2Test, dans laquelle vous mettrez les scénarios demandés ci-après.

  3. À l’aide de Mockito, implémentez les scénarios de tests suivants pour la méthode seeCurrentMeeting :

    1. S’il est 13:00 lors d’une journée donnée, et qu’il existe un unique meeting se déroulant de 11:00 à 12:00 de la même journée, alors null est obtenu en valeur de retour.

    2. S’il est 11:30 lors d’une journée donnée, et s’il existe un unique meeting se déroulant de 11:00 à 12:00 de la même journée, alors le meeting est bien obtenu en valeur de retour.