Licence 3 Informatique – Génie Logiciel

Ce TP permet de découvrir et de mettre en œuvre Gradle dans Eclipse ainsi que l’utilisation de mocks avec Mockito pour réaliser des tests unitaires. Vous apprendrez à configurer un projet Gradle, intégrer des bibliothèques externes, et écrire des tests unitaires avec des doublures d’objets.

D'après le document Licence 3 Informatique – Génie Logiciel

Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

Licence 3 Informatique – Génie Logiciel

Document source

Licence 3 Informatique – Génie Logiciel

Programming, Software Engineering, Testing · PDF · 3 pages

Afficher l'aperçu du document

Consulter le document original →

Ce TP permet de découvrir et de mettre en œuvre Gradle dans Eclipse ainsi que l’utilisation de mocks avec Mockito pour réaliser des tests unitaires. Vous apprendrez à configurer un projet Gradle, intégrer des bibliothèques externes, et écrire des tests unitaires avec des doublures d’objets. Pour suivre ce TP, vous aurez besoin d’Eclipse avec le plugin Buildship et d’une connaissance de base en Java et tests unitaires.

Objectifs

  • Savoir configurer Eclipse pour utiliser Gradle
  • Utiliser des mocks dans le cadre de tests unitaires avec Mockito
  • Écrire des tests unitaires pour un jeu de dés simple
  • Manipuler des doublures d’objets pour contrôler le comportement lors des tests

Prérequis et configuration

  • Eclipse avec le plugin Buildship installé (normalement présent dans les salles de TP)
  • Connaissances de base en Java et tests unitaires
  • Gradle pour la gestion de projet et des dépendances
  • Mockito 2.x pour la création de mocks

Mise en place de Gradle

Dans cette première étape, vous allez créer un projet Gradle dans Eclipse afin de gérer la construction et les dépendances de votre projet.

Procédure :

  • Dans Eclipse, créez un nouveau projet Gradle via Nouveau Projet > Projet Gradle.
  • Repérez les fichiers build.gradle et settings.gradle qui configurent le projet Gradle.

Pourquoi ? Ces fichiers permettent de définir les dépendances, les plugins et les paramètres de construction du projet.

Résultat attendu : Un projet Gradle créé avec les fichiers de configuration visibles dans l’explorateur.

Utilisation de Gradle pour intégrer Mockito

Vous allez maintenant modifier la configuration Gradle pour ajouter la bibliothèque Mockito, nécessaire pour la création de mocks dans les tests unitaires.

Procédure :

  • Ouvrez le fichier build.gradle.
  • Dans la section repositories { ... }, ajoutez la ligne jcenter().
  • Dans la section dependencies { ... }, ajoutez la ligne testCompile "org.mockito:mockito-core:2.+".
  • Dans Eclipse, faites un clic droit sur le projet, puis sélectionnez Gradle > Refresh Gradle Project pour appliquer les modifications.

Pourquoi ? Cela permet à Gradle de télécharger et intégrer la bibliothèque Mockito dans le projet pour les tests.

Résultat attendu : La dépendance Mockito est ajoutée et disponible pour les tests unitaires.

Jeu de dés : création et test du dé

Dans cet exercice, vous allez créer une classe représentant un dé à 6 faces et écrire des tests unitaires pour vérifier son comportement.

Spécifications :

  • Le dé retourne un entier aléatoire entre 1 et 6 lorsqu’il est lancé.
  • La classe Dé prend en paramètre un objet de type Random dans son constructeur.
  • La méthode principale est public int lancer().

Procédure :

  • Écrivez un test pour vérifier que les valeurs retournées par lancer() sont bien comprises entre 1 et 6.
  • Créez une classe NoRandom héritant de Random et surchargeant la méthode nextInt(int m) pour toujours retourner 7.
  • Écrivez un test qui vérifie que l’utilisation de NoRandom dans le dé provoque une exception de type RunTimeException.
  • Modifiez le test pour vérifier également le comportement lorsque la valeur retournée est inférieure à 1.

Pourquoi ? Ces tests garantissent que la classe Dé respecte les contraintes sur les valeurs retournées et gère correctement les erreurs.

Résultat attendu : Les tests valident que le dé lance des valeurs entre 1 et 6, et que les valeurs hors bornes génèrent une exception.

Amélioration des tests du dé avec Mockito

Plutôt que de créer une classe spécifique pour simuler des comportements particuliers de Random, vous allez utiliser Mockito pour créer des mocks.

Procédure :

  • Créez un mock de Random avec la commande :
Random tooMuch = mock(Random.class);
when(tooMuch.nextInt(anyInt())).thenReturn(7);
  • Utilisez ce mock dans la classe Dé pour tester le comportement lorsque la valeur retournée est supérieure à 6.

Pourquoi ? Mockito simplifie la création de doublures d’objets et évite d’écrire des classes spécifiques pour chaque cas de test.

Résultat attendu : Le test avec mock valide que l’exception est levée lorsque la valeur dépasse 6.

Le joueur et son test

Vous allez maintenant créer une classe Joueur qui utilise le dé pour lancer deux fois et garder la valeur maximale.

Procédure :

  • Écrivez un test vérifiant le comportement du lancer d’un joueur.
  • Créez la classe Joueur avec un constructeur prenant en paramètre le nom du joueur et le dé utilisé.
  • Modifiez la classe pour que le joueur lance deux fois le dé et conserve la meilleure valeur.
  • Créez un mock du dé pour vérifier que la méthode lancer() est appelée exactement deux fois :
Dice mockDe = mock(Dice.class);
...
verify(mockDe, times(2)).lancer();
  • Proposez une solution similaire pour vérifier que le joueur conserve bien la valeur maximale des deux lancés.

Pourquoi ? Cela permet de s’assurer que le joueur ne triche pas en lançant le dé un nombre incorrect de fois et qu’il garde la bonne valeur.

Résultat attendu : Les tests confirment que le joueur lance deux fois le dé et garde la valeur maximale.

Le jeu de dé

Enfin, vous allez créer une classe JeuDeDé qui met en compétition deux joueurs selon les règles suivantes :

  • Chaque joueur lance son dé.
  • Le joueur avec le plus grand tirage gagne.
  • En cas d’égalité, les joueurs rejouent jusqu’à 5 essais.
  • Si après 5 essais il n’y a toujours pas de vainqueur, il n’y a pas de gagnant.

Procédure :

  • Écrivez une classe de test pour JeuDeDé utilisant des mocks pour contrôler les résultats des joueurs et vérifier que le gagnant est correctement déterminé.
  • Utilisez des mocks pour tester le cas où il n’y a pas de gagnant après 5 essais.
  • Implémentez la classe JeuDeDé en respectant ces règles.

Pourquoi ? Les mocks permettent de simuler différents scénarios de jeu pour tester la logique de la classe sans dépendre du hasard.

Résultat attendu : Les tests valident que le jeu détermine correctement le gagnant ou l’absence de vainqueur après 5 essais.

Résultats attendus

  • Projet Gradle correctement configuré dans Eclipse avec les fichiers build.gradle et settings.gradle.
  • Bibliothèque Mockito intégrée et disponible pour les tests.
  • Classe Dé qui lance des valeurs entre 1 et 6, avec gestion des exceptions pour valeurs hors bornes.
  • Tests unitaires utilisant des mocks pour simuler des comportements spécifiques de Random et du dé.
  • Classe Joueur qui lance deux fois le dé et conserve la meilleure valeur, vérifiée par tests avec mocks.
  • Classe JeuDeDé qui gère une partie entre deux joueurs avec règles d’égalité et limite de 5 essais, testée avec mocks.

Pièges courants

  • Ne pas rafraîchir le projet Gradle après modification du fichier build.gradle, ce qui empêche la prise en compte des dépendances.
  • Oublier d’ajouter jcenter() dans les repositories, empêchant la résolution de Mockito.
  • Ne pas passer un objet Random dans le constructeur du dé, ce qui rend les tests non reproductibles.
  • Écrire des doublures d’objets manuelles (comme NoRandom) alors que Mockito peut simplifier leur création.
  • Ne pas vérifier le nombre d’appels à la méthode lancer() dans les tests du joueur, ce qui peut masquer un comportement incorrect.
  • Omettre de tester le cas d’égalité répétée dans le jeu de dés, ce qui peut conduire à des erreurs logiques.

Partager

Commentaires

Aucun commentaire pour le moment. Posez la première question.

Les commentaires sont relus avant publication. Votre e-mail n'est jamais affiché.

← Toutes les révisions