Checklist activité intégrative
Itération 1
- La structure des fichiers corresponds à celle montrée dans le PDF
AI-1 : Créer une partie
En tant que joueur, je souhaite démarrer une nouvelle partie afin de l’afficher à l’écran
- L’application démarre en affichant un menu principal composé de deux items : « Nouvelle partie » et « Quitter »
- L’activation de l’item « Nouvelle partie » débute la création d’une partie.
- La création d’une partie commence par le chargement de la carte depuis le fichier resources/maps/map-sample.txt. Nous vous fournissons à cette fin la classe treasurequest.io.CharArrayFileReader.
- Une fois la carte chargée, l’application y place des trésors sur les cases creusables. Une case est creusable si elle n’est pas de type Eau.
- Le nombre de trésors à placer correspond à 10% du nombre de cases creusables, avec au moins 1 trésor à trouver.
- La valeur d’un trésor est un nombre aléatoire allant de 10 à 20 pièces.
- Toutes les cases sont non-creusées.
- Une case active est désignée. Elle correspond à une case du centre de la carte.
- Le joueur possède une bourse correspondant à 2 fois le nombre de trésors. Cette bourse est exprimée en pièces (s’il y 20 trésors à placer, la bourse de départ du joueur sera de 40 pièces).
Tests d'intégration
- Quand je lance l’application, celle-ci me présente le menu principal composé de deux items « Nouvelle partie » et « Quitter »
- Quand je sélectionne l’item « Quitter », l’application termine son exécution.
- Quand je sélectionne l’item « Nouvelle partie », l’application change d’écran
AI-2 : Voir une partie
En tant que joueur, je souhaite voir l’état d’une partie afin de décider des actions à entreprendre
- Une seconde vue présente l’état de la partie.
- Une carte montre les cases. En début de partie, aucune case n’est creusée.
- La case active de départ est au « centre » de la carte.
- Un panneau affiche la bourse du joueur, le nombre de trésors à trouver et le cout à payer pour creuser la case active.
- Creuser une case Sable coute 1 pièce. Le cout des autres types de cases est déduit de cette valeur.
Tests d’acceptation
Important : pour les tests d’acceptation, nous utiliserons des cartes autres que celles fournies.
- Quand je lance une nouvelle partie, l’application me présente la carte donnée dans l’exemple.
- Quand je lance une nouvelle partie, la case active est celle au « centre » de la carte
- Quand je lance une nouvelle partie, l’application me dit qu’il y a XX trésors à trouver, que le joueur à une bourse de 2*XX
- Quand je lance une nouvelle partie, l’application m’affiche le cout correct de la case active
AI-3 : Revenir au menu principal
En tant que joueur, je peux abandonner une partie et revenir au menu principal, afin d’en relancer une nouvelle.
- Appuyer sur la touche « Esc » quand une partie est en cours permet de revenir à l’écran principal.
- Demander une nouvelle partie relance la création d’une nouvelle partie. En particulier, le rechargement de la carte.
Tests d’acceptation
- Soit une partie lancée avec une case creusée, quand je reviens au menu principal et que je relance une nouvelle partie, le jeu revient à son état de départ.
- Soit une partie lancée, quand je change le fichier à charger et que je reviens au menu principal, alors l’application présente la carte du nouveau fichier
Questions supplémentaires d'algo et de POO
- Indiquer la CTT du placement des trésors sur les cases creusables dans la javadoc en entête de CaseMap (Pour répondre à cette question, examinez la partie de votre code concernée, et identifiez les boucles, les imbrications, mais aussi les collections utilisées et leurs opérations ou les appels de sous-méthodes ou de méthodes d’autres objets. Quand vous répondez, n’oubliez pas d’indiquer à quoi correspondent vos libellés N,M, etc)
- Les Superviseurs collabore avec la fabrique (Factory) de Game au travers d'une interface
- Les classes sont dans
treasurequest.domains
et n'ont pas de lien avec les vues (tout ce qui pourrait être en dehors dedomains
) - L'encapsulation (attributs private) et les copies défencives sont bien effectuées sur toutes les classes du domains
- Ecrire des méthodes courtes et peu complexes (et tenter de respecter la règle de Demeter)
- Ecrire des classes timides (c'est à dire qui font le boulot et qui ne nécessite pas de tout le temps leur demander des choses depuis d'autres classes)
- Bon usage du polymorphisme
- Bonne utilisation des interfaces
- Aucune alerte PMD
- Tests unitaires JUnit5 dans le dossier
tests
qui donne un coverage d'au moins 90% sur chaque classe du domains (pour un degré de maitrise supplémentaire → coverage de 100% de ces classes)