IUT Charlemagne - Dept info 2020-2021

Programmation 1 DUT 1A

Projet à rendre - Poquemont Vazy ! !

1 Projet à rendre
Ce projet est un projet à faire de manière individuelle et à rendre à votre encadrant
via le module Programmation1 sur arche. Il donnera lieu à une évaluation qui comptera
à hauteur de 15% dans la note finale du module.
Vous devrez rendre IMPERATIVEMENT pour le jeudi 12/11/2020 sur arche :
des sources commentées qui compilent : tout problème dans la compilation
ou l’absence de commentaire entrainera des points en moins ;
une version déjà compilée de votre programme ;
des classes de test complétées et intégralement commentées (cf fin de l’énoncé) ;
un répertoire contenant la javadoc générée à partir de votre projet.

ATTENTION :
Veuillez respecter IMPERATIVEMENT les noms des classes et méthodes
que l’on vous donne (majuscule comprise, sans accent et sans faute d’orthographe
- cf conventions en annexe du polycopié). Respectez aussi l’ordre des paramètres
dans les fonctions ou méthodes.
Tous les attributs doivent être déclarés en private, les méthodes sont déclarées
en public sauf précision dans l’énoncé.
Les méthodes ne doivent contenir aucun System.out.println sous peine de ne
pas pouvoir être corrigées facilement. Des points pourront être retirés si cette
consigne n’est pas respectée.
Votre projet est à faire en individuel uniquement, tous les projets seront
testés par une application capable de détecter automatiquement les tentatives
de fraude et nous sévirons si besoin (comme cela a déjà été fait par le passé).

2 Présentation du projet
Les étoiles sont alignées et l’ultime tournoi Poquémont va enfin pouvoir se dérouler.
Les plus grands dresseurs sont présents et vont s’affronter dans des combats sans
précédents. Qui se révèlera être le plus grand dresseur ? Qui parmi Didjeridoo, Plan-
tedeschoux et Cartapus sera le poquémont le plus performant ? C’est ce que tous les
spectateurs attendent de voir.
Le projet va avoir pour objectif de représenter (très simplement) un combat entre les
dresseurs. Les dresseurs se trouvent dans une arène dans laquelle se trouvent différents

Prog1 - TD à rendre - Poquemont Vazy ! ! 1

poquémonts. Les dresseurs se déplacent dans l’arène selon deux axes (x et y) et ne
peuvent traverser les murs de l’arène. Lorsqu’un dresseur se trouve au même endroit
qu’un poquémont, il peut le capturer pour l’utiliser ensuite comme arme contre les
autres dresseurs. Mais, un dresseur ne peut disposer que d’un seul poquémont et pour
en capturer un autre, il doit d’abord déposer celui qu’il a précédemment capturé.
Un dresseur peut attaquer un autre dresseur si ce dernier est à une distance inférieure
ou égale à la portée du poquémont utilisé. Quand un dresseur n’a pas de poquémont, il
peut quand même attaquer à mains nues mais il ne fait que 1 de dégât avec une portée
de 1.
L’objectif de ce projet est de programmer plusieurs classes pour modéliser l’arène,
les poquémonts, les dresseurs, leurs déplacements et les combats qui ont lieu :
la classe Arene a pour objectif de représenter l’arène et les murs intérieurs ;
la classe Poquemont a pour objectif de représenter un poquémont avec sa portée
et ses dégâts ;
la classe Dresseur a pour objectif de représenter un dresseur avec son nom, ses
points de vie et le poquémont éventuel qu’il a capturé.

3 Structuration du projet
3.1 Répertoires
Le fichier .zip fourni sur arche vous donne une structure à respecter pour votre
projet. Il contient la structure de sous-répertoires suivante que vous devrez respecter
pour votre sujet :
un répertoire principal gr Z nom dont le nom est à modifier
Z doit désigner votre numéro de groupe
nom doit désigner votre nom
ce répertoire contient plusieurs sous-répertoires
un répertoire src qui doit contenir les fichier .java ;
un répertoire javadoc qui contiendra le résultat de la javadoc.

3.2 Notion de packages

Un package a pour objectif de rassembler des classes. Les classes d’un même package
se situent dans le même répertoire.
Chacune des classes du package commence par la ligne de déclaration package
nom package; où nom package désigne le nom du package. Ces classes doivent rester
dans le répertoire du nom du package.
Le nom complet de la classe inclut le nom du package suivi d’un point. Par exemple le
véritable nom de la classe Modele du package graphisme est donc graphisme.Modele.
Jusqu’à présent vous n’aviez qu’un seul package libtest, désormais, le projet est
structuré en plusieurs packages réunis dans le répertoire src
le package application contient les classes Arene, Dresseur et Poquemont que
vous devrez programmer ;

Prog1 - TD à rendre - Poquemont Vazy ! ! 2

 le package libtest contient les classes utiles pour lancer les tests (comme en
TP) ;
le package test contient les classes de test à compléter (on sépare les classes de
test de l’application) ;
le package graphisme contient des classes permettant d’interagir avec vos classes
à l’aide d’une interface graphique.
Seules les classes des packages application et test seront à modifier.

3.3 Utilisation des classes d’un package

Il est possible d’utiliser les classes d’un autre package grâce à la commande import
suivie du nom complet de la classe. Par exemple, import java.util.Scanner demande
à java d’utiliser la classe Scanner située dans le package java.util.
ATTENTION : Pour pouvoir utiliser correctement les classes des packages, il faut
compiler et exécuter les programmes JAVA à partir de l’intérieur du répertoire src.
Pour compiler les classes du package, il suffit d’aller dans le répertoire src du projet
et de compiler tous les fichiers .java contenus dans le sous-répertoire du package (par
exemple graphisme).
1 javac graphisme /* . java

Pour lancer la classe principale Principale, il faut se mettre dans le répertoire src du
projet 1 et utiliser le nom complet de la classe graphisme.Principale
1 java graphisme . Principale

3.4 le package graphisme

Le package graphisme propose une application graphique permettant de vérifier vi-
suellement que votre application fonctionne. Il ne permet pas de tester votre application
(ce sont les classes de test qui sont chargées de le faire), mais de pouvoir interagir avec
elle. Vous verrez en S2 comment il est possible de construire une interface graphique
comme celle présentée ici.
La figure 1 montre le rendu obtenu à l’écran lorsqu’on exécute
1 java graphisme . Principale

On peut contrôler un dresseur en utilisant les boutons situés dans sa colonne :

les boutons de la croix directionnelle permet de déplacer le dresseur ;
les trois autres boutons permettent au dresseur de prendre le premier poquémont
de sa case, d’attaquer le dresseur le plus proche et de poser le poquémont qu’il
possède.
1. et PAS dans le sous-répertoire graphisme

Prog1 - TD à rendre - Poquemont Vazy ! ! 3

Figure 1 – Rendu visuel de l’application avec les classes du package graphisme. La colonne
centrale présente le jeu en cours avec deux dresseurs et quatre poquémonts. La colonne de
gauche présente les informations du dresseur vert ”D 0” et la colonne de droite les informations
du dresseur rouge ”D 1”.

4 La classe Arene
Écrire la classe Arene à l’aide des indications suivantes.

4.1 Attributs

La classe Arene du package application a pour objectif de représenter l’arène dans

laquelle les dresseurs évoluent et les murs intérieurs qui empêchent leurs déplacements.

Un objet de type Arene possède pour attribut

un entier tailleX correspondant à la taille de l’arène selon l’axe des abscisses ;
un entier tailleY correspondant à la taille de l’arène selon l’axe des ordonnées.
Les cases de l’arène sont représentées par des couples d’entiers (x,y) avec x compris
dans l’intervalle [0..tailleX-1] et y dans l’intervalle [0..tailleY-1]

4.2 Constructeurs

La classe Arene possède un simple constructeur sans paramètre qui initialise chacun
de ses deux attributs en leur donnant pour valeur 10. L’arène est donc constituée de
100 cases.

Prog1 - TD à rendre - Poquemont Vazy ! ! 4

4.3 Accesseurs
Afin de pouvoir accéder aux attributs privés, on vous demande d’écrire des méthodes
retournant les valeurs des attributs. Ces méthodes sont appelées accesseurs et s’écrivent
habituellement sous la dénomination anglaise getNom() où Nom désigne le nom de l’at-
tribut.

Écrire les deux accesseurs getTailleX et getTailleY qui retournent l’attribut cor-
respondant.

4.4 Méthodes
La classe Arene possède en outre une seule méthode nommée etreAccessible.
Cette méthode prend deux entiers x et y en paramètre et retourne un booléen précisant
si la case de coordonnées (x,y) est accessible (autrement dit n’est pas un mur).
Pour cela, on ne considéra qu’une seule arène de forme donnée 2 par la figure 2.

Axe Abscisses (x)

0 1 2 3 4 5 6 7 8 9

2
Axe Ordonnées (y)

Figure 2 – Structure de l’arène à utiliser. La taille de l’arène étant de 10 dans chaque

direction, les axes sont indexés par des nombres dans l’intervale [0..9].

Ainsi, la méthode etreAccessible retourne false uniquement

si x fait sortir du labyrinthe (c’est à dire n’est pas compris entre 0 et tailleX-1) ;
si y fait sortir du labyrinthe (c’est à dire n’est pas compris entre 0 et tailleY-1) ;
ou si (x,y) correspond à une case de mur.
A l’aide de quelques conditionnelles, calculez la valeur du booléen à retourner. Vous
pourrez raisonner par colonne pour simplifier les conditions.

4.5 Classe de Test

Une première classe de test test.TestArene est fournie. Elle permettra de vérifier
que votre constructeur et votre méthode fonctionnent correctement. Les autres classes
2. vous verrez en fin de prog1 comment changer les contenus des arènes

Prog1 - TD à rendre - Poquemont Vazy ! ! 5

de test seront à écrire.

5 La classe Poquemont

Écrire la classe Poquemont du package application avec les indications suivantes.

5.1 Attributs

Le classe Poquemont a pour objectif de représenter un poquémont qu’un dresseur

pourra capturer pour combattre d’autres dresseurs. Un poquémont est caractérisé par
plusieurs attributs :
un attribut entier degats précisant les dégâts que fait le poquémont lorsqu’il
attaque ;
un attribut entier portee désignant la portée de l’attaque du poquémont ;
un attribut arene de type Arene désignant l’arène dans laquelle se trouve le
poquémont ;
deux attributs entiers posX et posY désignant la position du poquémont dans
l’arène ;
un attribut porteur de type Dresseur permettant de savoir quel dresseur a
capturé le poquémont. Si aucun dresseur n’a capturé le poquémont, le poquémont
est libre et l’attribut porteur vaut null.

5.2 Constructeurs

La classe Poquemont possède deux constructeurs :

un constructeur avec un paramètre pArene de type Arene qui construit un
poquémont par défaut. Ce poquémont fait 2 de dégâts et a une portée de 2. Il
n’est possédé par aucun dresseur, se trouve dans l’arène pArene et est positionné
pas défaut dans l’arène (ses valeurs initiales de x et y sont 5). On SUPPOSE que
cette case est toujours accessible dans l’arène ;

un constructeur qui prend en entrées cinq paramètres. Ces paramètres sont dans
l’ordre
— (1) int x qui représente l’abscisse initiale du poquémont ;
— (2) int y qui représente l’ordonnée initiale du poquémont ;
— (3) int pDegats qui représente les dégâts faits par le poquémont ;
— (4) int pPortee qui représente la portée du poquémont ;
— (5) pArene qui correspond à l’arène dans laquelle évolue le poquémont.
La position initiale du poquémont doit être dans une case accessible de l’arène,
sinon sa position sera par défaut de (0,0) (supposée accessible). Les dégâts et
la portée doivent être positifs ou nuls. Lorsque l’un des paramètres est négatif,
la valeur de l’attribut correspondant doit être de 0.

Prog1 - TD à rendre - Poquemont Vazy ! ! 6

5.3 Méthodes Accesseurs
Écrire les méthodes getDegats, getPortee, getPorteur, getPosX et getPosY.

Attention ! Sauf indication contraire, ces accesseurs ne doivent servir que dans vos
méthodes de test pour vérifier les bonnes valeurs des attributs.

5.4 Autres Méthodes

etrePris : Écrire la méthode etrePris qui prend en paramètre un objet dresseur
de type Dresseur et modifie le statut du poquémont pour spécifier qu’il a été
capturé par ce dresseur. Pour que cela soit possible, il faut que le poquémont
soit encore libre et qu’il se trouve dans la même arène et à la même position que
le dresseur qui souhaite le capturer. Dans le cas contraire, aucun changement
n’est fait. Cette méthode retourne un booléen qui vaut true si et seulement si le
dresseur a pu capturer le poquémont. Cette méthode peut appeler les méthodes
getArene(), getPosX et getPosY de la classe Dresseur.

etreDepose : Écrire la méthode etreDepose. Cette méthode ne prend aucun

paramètre et modifie le statut du poquémont pour spécifier qu’il a été libéré
par un dresseur et qu’il est à nouveau libre. Cette méthode retourne un booléen
qui vaut true si et seulement si le poquémont appartenait à un dresseur et a
été libéré. Comme le poquémont est déplacé en même temps que le dresseur qui
le porte, il doit se trouver à la position du dresseur qui l’a libéré (cf méthode
seDeplacer de Dresseur).

changerPosition : Écrire la méthode changerPosition qui ne prend aucun

paramètre et ne retourne rien. Cette méthode est appelée à chaque fois qu’un
dresseur se déplace pour mettre à jour la position du poquémont qu’il a capturé
et qui se déplace avec lui. Cette méthode peut appeler les méthodes getPosX et
getPosY de la classe Dresseur.

toString : Écrire la méthode toString qui affiche la chaine "-poquemont"

suivie de ses degats et de sa portée sous la forme suivante 3
"-poquemont(d:degats,p:portee )"
où degats et portee représentent les valeurs de ces attributs.
Ainsi, la chaine associée à un poquémont ayant une portée de 5 et faisant 2 de
dégâts doit être "-poquemont(d:2,p:5)"

5.5 Tests
A l’aide des indications section 7, écrire le début de la classe de test TestPoquemont
associée à la classe Poquemont. Limitez-vous à tester les constructeurs et les méthodes

3. parenthèses incluses, pas d’accent, pas d’espace entre les virgules ou les :

Prog1 - TD à rendre - Poquemont Vazy ! ! 7

simples qui n’impliquent pas la classe Dresseur 4 .

6 La classe Dresseur
Écrire la classe Dresseur du package application avec les indications suivantes.

6.1 Attributs
Le classe Dresseur a pour objectif de représenter un dresseur. Un dresseur est
caractérisé par plusieurs attributs
un attribut String nom correspondant au nom du dresseur ("Sacha", ...) ;
deux attributs entiers posX et posY précisant la position du dresseur dans l’arène
- le dresseur doit toujours se trouver sur une case accessible ;
un attribut poquemontDresse de type Poquemont permettant de savoir quel
poquémont le dresseur a capturé. Si le dresseur n’a pas de poquémont avec lui 5 ,
cet attribut vaut null.
un attribut pv de type entier correspondant au nombre de points de vie du
dresseur. Cet attribut ne peut pas être négatif.
un attribut arene de classe Arene correspondant à l’arène dans laquelle le dres-
seur évolue.

6.2 Constructeurs
La classe Dresseur possède deux constructeurs :
un constructeur avec un paramètre pArene de type Arene qui construit un objet
Dresseur par défaut. Ce dresseur s’appelle "Sacha", a une valeur initiale de posX
de 0, une valeur initiale de posY de 0, possède 5 points de vie, n’a capturé aucun
poquémont et se trouve dans l’arène passée en paramètre. On SUPPOSERA que
le paramètre arene est correct (et on ne le testera pas) ;

un constructeur qui prend quatre paramètres en entrée : un String pNom corres-

pondant au nom du dresseur, deux entiers departX et departY correspondant à
sa position initiale et un objet pArene de type Arene. Ce constructeur construit
un dresseur dont le nom correspond à pNom, qui possède 5 points de vie, qui
pour position initiale les coordonnées (departX, departY), qui n’a capturé au-
cun poquémont et qui évolue dans l’arène pArene. Si la position de départ n’est
pas accessible au sein de l’arène, le dresseur est placé à la position (0,0). On
SUPPOSERA que le paramètre arene est correct (et on ne le testera pas).

6.3 Méthodes accesseurs

Écrire les méthodes getPoquemontDresse, getPv, getNom, getArene, getPosX et
getPosY.
4. Vous pouvez soit créer une classe Dresseur avec des méthodes vides soit mettre en commentaire les tests
qui impliquent cette classe
5. qu’il n’en ait jamais capturé ou qu’il ait libéré son ancien poquémont

Prog1 - TD à rendre - Poquemont Vazy ! ! 8

 Attention !, ces accesseurs ne doivent servir que dans vos méthodes de test pour
vérifier les bonnes valeurs des attributs. Ils ne doivent pas être utilisés dans les
classes Dresseur et Poquemont - sauf indication contraire dans le descriptif de
la méthode.

6.4 Autres Méthodes

prendrePoquemont : Écrire la méthode prendrePoquemont. Cette méthode prend
un paramètre poq de type Poquemont correspondant au poquémont que le dres-
seur souhaite capturer et retourne un booléen. Avec cette méthode, le dresseur
capture le poquémont et peut ensuite attaquer avec. Cela ne fonctionne que
si le paramètre poq n’est pas null, si le poquémont se trouve dans la même
arène et sur la même case que celle du dresseur, si le dresseur ne possède aucun
poquémont et si le poquémont poq est libre. Cette méthode met à jour le statut
du dresseur et du poquémont et retourne un booléen valant true si et seulement
si le dresseur a pu capturer le poquémont. Cette méthode ne peut fonctionner
que si le dresseur n’est pas blessé.

deposerPoquemont : Écrire la méthode deposerPoquemont. Cette méthode ne

prend aucun paramètre en entrée et permet à un dresseur de déposer un poquémont
qu’il aurait en sa possession. Cette méthode met à jour les attributs concernés
et retourne un boolean qui vaut true si et seulement le poquémont a bien été
posé. Si le dresseur n’a pas de poquémont en sa possession lorsque la méthode est
appelée, la méthode doit retourner false. Cette méthode ne peut fonctionner
que si le dresseur n’est pas blessé.

seDeplacer : Écrire la méthode seDeplacer qui prend en paramètre deux en-

tiers dx et dy. Ces entiers correspondent à la valeur de déplacement du dresseur
(c’est à dire la variation de position).
— Par exemple si le dresseur se trouve à la position (2,3), un déplacement de
(0,1) l’amènera à la position (2,4).
— Le dresseur ne peut se déplacer que d’une case, diagonales non comprises (il
faut que la somme des valeurs absolues de dx et dy soit égale à 1, sinon il ne
se déplace pas). Par exemple, si les paramètres sont (1,-1), le dresseur doit
rester sur la même case.
— Les déplacements du dresseur sont limités par l’arène dans laquelle il se
trouve : il ne peut sortir de l’arène ou aller dans une position correspondant
à un mur (on utilisera la méthode etreAccessible).
— Lorsque le dresseur se déplace, le poquémont qu’il porte (s’il en porte un)
doit se déplacer avec lui.
— Cette méthode ne peut fonctionner que si le dresseur n’est pas blessé.
subirDegats : Écrire la méthode subirDegats qui prend un entier degat en
paramètre et réduit les points de vie du dresseur de ces dégâts. Les dégâts ne
peuvent pas être négatifs (sinon rien ne se passe) et un dresseur ne peut jamais
avoir moins de 0 points de vie.

Prog1 - TD à rendre - Poquemont Vazy ! ! 9

 etreBlesse : Écrire la méthode etreBlesse qui ne prend pas de paramètre et
retourne un booléen qui vaut true si et seulement le dresseur est à 0 points de vie.

getDegats : Écrire la méthode getDegats. Cette méthode ne prend aucun pa-

ramètre et retourne un entier correspondant aux dégâts de l’attaque du dresseur.
Si le dresseur possède un poquémont, les dégâts de l’attaque correspondent aux
dégâts du poquémont, sinon, ces dégâts valent 1. Cette méthode pourra utiliser
la méthode getDegats de Poquemont.

getPortee : Écrire la méthode getPortee. Cette méthode ne prend aucun pa-

ramètre et retourne un entier correspondant à la portée de l’attaque du dresseur.
Si le dresseur possède un poquémont, la portée de l’attaque correspond à la
portée du poquémont, sinon, la portée vaut 1. Cette méthode pourra utiliser la
méthode getPortee de Poquemont.

getDistance : Écrire la méthode getDistance. Cette méthode prend en pa-

ramètre un objet victime de classe Dresseur. Elle retourne un entier correspon-
dant à la distance entre this et le dresseur passé en paramètre. Cette distance
est la distance de Manhattan (cf image 3) et ne tient pas compte des murs (les
attaques des Poquémont traversent les murs).

distance de 1

distance de 2 Quel que soit le chemin suivi, distance est de 8

Figure 3 – Distance de Manhattan entre les cases : distance minimale en suivant une ligne
brisée à angle droit suivant les axes x et y.

attaquer : Écrire la méthode attaquer qui permet à un dresseur d’attaquer un

autre dresseur. Cette méthode prend en paramètre la cible de l’attaque victime
de type Dresseur. Cette méthode consiste à retirer les points de dégâts de l’at-
taque aux points de vie de la cible. Cela ne peut se faire que si la cible est dans
la même arène que l’attaquant et si elle est à portée (en fonction de la portée
de l’attaque du dresseur et de la distance entre les dresseurs). Bien entendu, un
dresseur ne peut attaquer que s’il n’est pas blessé. La méthode doit retourner un
booléen qui vaut true si et seulement si l’attaque a été portée.

Prog1 - TD à rendre - Poquemont Vazy ! ! 10

 toString : Écrire la méthode toString qui permet d’afficher le statut du dres-
seur. Cette méthode retourne une chaine de la forme :
dresseur(nom-dresseur :pv )-poquemont(d:dégats,p:portée )
où
— nom-dresseur désigne le nom du dresseur ;
— pv désigne les points de vie du dresseur ;
— dégats désigne les dégâts du poquémont possédé par le dresseur ;
— portée désigne la portée du poquémont possédé par le dresseur.
Si le dresseur ne possède pas de poquémont, l’affichage se limite à dresseur(nom-dresseur :pv ).

6.5 Tests
Écrire la classe de test TestDresseur, compléter la classe de test TestPoquemont
et valider l’ensemble des méthodes des deux classes Dresseur et Poquemont.

7 Tests
Avant de rendre votre projet, vous vérifierez que celui-ci fonctionne correctement
en développant une classe de test par classe écrite (comme celles que vous avez utilisées
pendant les TPs).
Pour cela, pour chaque classe (Arene, Dresseur et Poquemont), vous allez
réfléchir aux différents tests à écrire ;
ajouter ces tests dans la classe de test fournie ;
lancer vos tests et vérifier que votre classe fonctionne correctement par rapport
à vos attentes.

7.1 Sélection des tests

Normalement, chaque méthode et constructeur doit être testé pour tous les cas qui
peuvent se présenter. Il faut donc dans un premier temps :
déterminer toutes les méthodes et constructeurs à tester pour la classe qui vous
intéresse ;
déterminer les différents cas à tester pour chaque méthode ;
pour chaque cas à tester, décider des valeurs de départ utilisées pour faire le
test, les valeurs de retour attendues, faire le test et vérifier que les retours des
méthodes correspondent bien à vos attentes.
Voici, par exemple, les tests à faire pour tester la méthode etrePris(Dresseur
dresseur) de la classe Poquemont. Il est dit dans l’énoncé qu’un poquémont est capturé
seulement s’il est libre et si le dresseur se situe dans la même case. On peut donc
envisager plusieurs cas
soit le dresseur qui veut capturer le poquémont est sur sa case et le poquémont
est capturé ;
soit le dresseur qui veut capturer le poquémont n’est pas sur la même case et le
poquémont reste au sol ;
soit le paramètre dresseur vaut null et le poquémont reste au sol.

Prog1 - TD à rendre - Poquemont Vazy ! ! 11

 d’autres cas sont à envisager en fonction du statut du poquémont (libre ou déjà
capturé par un autre dresseur) ...
Un moyen simple et rapide pour présenter les tests à effectuer consiste à utili-
ser l’application freeplane 6 . Freeplane permet de construire des cartes cognitives
(MindMapping en anglais) et de représenter graphiquement de l’information sous une
forme arborescente (cf. figure 4).
Cet outil est uniquement destiné à vous aider, on NE demande PAS de rendre le
résultat dans votre projet.

Figure 4 – Tests présentés sous forme de carte cognitive avec freeplane

7.2 Écriture de la classe de Test

Une fois l’ensemble des cas de test déterminés, il reste à vérifier que tous les tests
sont validés lorsque votre programme s’exécute. Vous complèterez les classes de test
correspondantes (TestPoquemont et TestDresseur) en ajoutant une méthode de test
pour chacun des cas identifiés.
6. Cette application est installée sur les machines de l’IUT et est téléchargeable gratuitement à l’adresse
http://freeplane.sourceforge.net/wiki/index.php/Main Page

Prog1 - TD à rendre - Poquemont Vazy ! ! 12

7.2.1 Organisation des méthodes de test

Les méthodes de test doivent IMPERATIVEMENT suivre les conventions de

nommage suivantes :
chaque méthode de test se trouve dans la classe correspondant à la classe à tester
(par exemple dans la classe TestPoquemont pour les méthodes de Poquemont) ;
le nom de chaque méthode de test
— débute par le mot ’test’ ;
— est suivie par le nom de la méthode testée précédé d’un underscore, par
exemple ’ EtrePris’ ;
— puis d’un descriptif sans accent du cas testé, par exemple ’ PriseOK’ ;
Ainsi, la méthode vérifiant que la méthode etrePris de la classe Poquemont fonc-
tionne bien quand le poquémont peut être pris s’appellera ’test EtrePris PriseOK().
Elle se trouvera dans la classe TestPoquemont.
Pour finir, chaque méthode de test est précédée d’un commentaire javadoc qui ex-
plique le cas que teste la méthode, par exemple ‘‘poquemont libre et dresseur
sans poquémont capturé’’.

7.2.2 Ajout d’une méthode de test

Une méthode de test a pour objectif de vérifier que le test est effectivement valide.
la méthode ne prend pas de paramètre et ne retourne rien ;
les premières instructions de la méthode préparent les données (en appelant des
constructeurs par exemple) ;
les instructions suivantes exécutent le test à proprement parler (à savoir la
méthode testée avec les bonnes données) ;
les instructions de vérification appellent la méthode assertEquals à chaque fois
qu’une condition attendue doit être vérifiée ;
vous pouvez utiliser les accesseurs pour vérifier les valeurs des attributs mais les
accesseurs n’ont pas besoin d’être testés (ils sont très simples).
Une fois qu’une méthode de test est écrite, elle doit rester dans votre classe de test.
Ainsi, à l’issue du projet, vos classes de test possèderont toutes les méthodes de tests
(une par cas à considérer) et permettront de tester l’ensemble de l’application.

7.2.3 Méthode assertEquals

Pour effectuer une vérification dans un test, il faut utiliser la méthode assertEquals.
Cette méthode possède le profil suivant :
void assertEquals(String erreur, Object attendu, Object obtenu)
erreur correspond au message d’erreur à afficher si la vérification n’est pas
correcte ;
attendu désigne la valeur attendue ;
obtenu désigne la valeur obtenue lors du test.

Prog1 - TD à rendre - Poquemont Vazy ! ! 13

 Par exemple, si on veut tester que le ’+’ correspond bien à la concaténation, on
ajouterait la chaine "bon" à la chaine "jour" et on vérifierait que le résultat serait
bien la chaine "bonjour".
1 String s1 = " bon " ;
2 String s2 = " jour " ;
3 String s3 = s1 + s2 ;
4 assertEquals ( " erreur : mauvaise concaténation " ," bonjour " , s3 );

7.2.4 Exemple

Pour le test de la méthode etrePris de la classe Poquemont, la classe TestPoquemont

s’écrirait de la manière suivante :
1 /** ****************
2 * test classe Poquemont
3 ** ** ** ** ** ** ** ** ** */
4 public class TestPoquemont {
5
6 /**
7 * quand le poquemont peut etre pris , poquemont libre et dresseur
8 * bonne case
9 */
10 public void test_etrePris_OK () {
11 Arene arene = new Arene ();
12 Poquemont poq = new Poquemont (5 , 5 , 2 , 2 , arene );
13 Dresseur d = new Dresseur ( " toto " , 5 , 5 , arene );
14 boolean res = poq . etrePris ( d );
15 assertEquals ( " resultat doit etre ok " , true , res );
16 assertEquals ( " poquemont doit etre pris " , d , poq . getPorteur ());
17 }
18

19 /**
20 * quand le poquemont ne peut pas etre pris , poquemont occupe et
21 * dresseur bonne case
22 */
23 public void t e s t _ e t r e P r i s _ n o n L i b r e () {
24 Arene arene = new Arene ();
25 Poquemont poq = new Poquemont (5 , 5 , 2 , 2 , arene );
26 Dresseur d = new Dresseur ( " toto " , 5 , 5 , arene );
27 boolean res = poq . etrePris ( d );
28 Dresseur d2 = new Dresseur ( " toto " , 5 , 5 , arene );
29 res = poq . etrePris ( d2 );
30 assertEquals ( " poquemont pas pris " , false , res );
31 assertEquals ( " ancien porteur reste " , d , poq . getPorteur ());
32 }
33
34 /**
35 * quand le dresseur est null
36 */
37 public void t e s t _ e t r e P r i s _ d r e s s e u r N u l l () {
38 Arene arene = new Arene ();

Prog1 - TD à rendre - Poquemont Vazy !! 14

39 Poquemont poq = new Poquemont (5 , 5 , 2 , 2 , arene );
40 Dresseur d = new Dresseur ( " toto " , 0 , 0 , arene );
41 boolean res = poq . etrePris ( null );
42 assertEquals ( " poquemont pas pris " , false , res );
43 }
44
45 /**
46 * quand le poquemont ne peut pas etre pris , poquemont libre et
47 * dresseur ailleurs
48 */
49 public void t e s t _ e t r e P r i s _ a i l l e u r s () {
50 Arene arene = new Arene ();
51 Poquemont poq = new Poquemont (5 , 5 , 2 , 2 , arene );
52 Dresseur d = new Dresseur ( " toto " , 0 , 5 , arene );
53 boolean res = poq . etrePris ( d );
54 assertEquals ( " poquemont pas pris " , false , res );
55 assertEquals ( " poquemont encore libre " , null , poq . getPorteur ());
56 }
57
58 /**
59 * quand le poquemont ne peut pas etre pris , poquemont libre et
60 * dresseur dans une autre arene
61 */
62 public void t e s t _ e t r e P r i s _ a u t r e A r e n e () {
63 Arene arene = new Arene ();
64 Poquemont poq = new Poquemont (5 , 5 , 2 , 2 , arene );
65 Arene arene2 = new Arene ();
66 Dresseur d = new Dresseur ( " toto " , 5 , 5 , arene2 );
67 boolean res = poq . etrePris ( d );
68 assertEquals ( " poquemont pas pris " , false , res );
69 assertEquals ( " poquemont encore libre " , null , poq . getPorteur ());
70 }
71
72
73 // ... autres tests de la classe Poquemont
74 }

7.3 Classes de test fournies

On vous fournit sur l’ENT le package libtest ainsi qu’un début des classes de test
TestPoquemont.java, TestDresseur.java et TestArene.java dans le package test.
Les classes de test fournies possèdent déjà :
— une méthode main qui lance tous les tests que vous aurez écrits dans la classe ;
— un premier test qui vérifie que vos méthodes sont correctement écrites ;
— quelques autres tests qui vérifient vos constructeurs (pour être sûr que vous créez
les bons objets).
Ces classes doivent compiler correctement si vos méthodes sont bien déclarées. Il
ne faut pas changer les tests initiaux qui vérifient que vos méthodes sont conformes au
sujet.

Prog1 - TD à rendre - Poquemont Vazy ! ! 15

 Une fois que vos tests seront ajoutés à cette classe, l’exécution de tous les tests ne
doivent conduire à aucune erreur (puisque tous vos tests doivent être validés). Faire de
bons tests est un moyen de vous assurer de rendre un projet conforme aux attentes.
ATTENTION, il ne vous est pas demandé de rendre un menu, mais de rendre
les classes de tests complétées par vos méthodes de test. Tout rendu autre que ce qui
est attendu ne sera pas évalué.

7.4 Démarche
Pour faire correctement votre projet, nous vous conseillons de penser à tous les tests
possibles dans un premier temps (cf partie sélection des test), de les programmer et
ensuite seulement de commencer à écrire les différentes classes de votre programme.
Cela vous permettra
— d’avoir pensé à tous les cas particuliers lorsque vous écrirez votre programme ;
— de disposer d’un programme plus sûr.

8 Génération de la javadoc
Pensez à écrire la javadoc dans vos fichiers sources et générez la javadoc dans le
répertoire javadoc situé à la racine de votre projet.
Pour cela, le plus simple est de se placer dans le répertoire gr Z nom et d’exécuter
la commande javadoc
avec l’option ’-d dest’ pour spécifier le répertoire de destination (ici le répertoire
de destination sera javadoc) ;
avec comme argument les fichiers sources du package application situés dans
src, à savoir ’src/application/*.java’.
1 javadoc -d javadoc src / application /* . java

La javadoc générée est à rendre avec votre projet.

Une fois la javadoc générée, il est possible de la consulter en ouvrant le fichier
javadoc/index.html.

9 Dernier conseil
Le projet que vous allez rendre forme un tout (classes + tests + javadoc).
— Si vous faites les bons tests, vous pourrez facilement détecter les erreurs de votre
projet et le corriger.
— Inversement si les tests ne sont pas complets, vous risquez d’avoir des classes qui
fonctionnent mal et un projet qui ne fournit pas les bons résultats.
Ainsi, le meilleur moyen d’avoir une bonne note est de mettre l’accent sur les tests
qui vous permettront d’écrire un code correct et valide (et bien entendu de corriger les
classes lorsque les tests ne passent pas).

Prog1 - TD à rendre - Poquemont Vazy ! ! 16

 Pour information, le fait d’écrire les tests dans le corrigé a permis d’éviter la présence
de plusieurs erreurs d’inattention dans le corrigé du projet. Ils vous assurent aussi
qu’une fois que votre projet est fini, tous les tests restent valides (vous n’avez donc pas
introduit une nouvelle erreur dans votre programme en faisant une modification).

Prog1 - TD à rendre - Poquemont Vazy ! ! 17