GEF320 Lab 5

Labo 5: BugBattle version 0.5

GEF320 Hiver 2016

Objectif

Ce laboratoire a pour objectif de vous initier aux cadres de test jUnit et au processus d’élaboration piloté par les tests. Il a aussi pour but de vous donner la chance de pratiquer la résolution de problèmes de design simples et la création de documentation de design avec le VP-UML. Pour ce faire, vous augmenterez les fonctions de BugBattle tel que décrit dans la demande de changement BugBattle v.0.5.

Remise et date d’échéance

Vous devez remettre votre rapport de laboratoire et le code source par courriel avant le début du prochain laboratoire. Vous devez remettre:

  • un rapport de laboratoire concis et bien mis en page (en format pdf) qui contient:
    • une introduction;
    • la documentation de design en UML tel que décrite ci-dessous;
    • une explication de votre stratégie de « créature intelligente » (voir tâche 0.5.7 de la demande de changement); et
    • une brève discussion sur ce que vous avez appris, les découvertes que vous avez faites, ce qui a été difficile dans le laboratoire (surtout l’utilisation des jUnit). Soyez concis!
  • Un fichier .zip contenant votre code source complètement commenté avec javadoc (référez-vous au guide de survie d’Eclipse pour les instructions d’exportation); et
  • Vous n’avez pas besoin de remettre les fichiers de vos modèles VP-UML que vous avez utilisé pour créer la documentation.

Tâches

Préparation

Installation

Créez un nouveau projet Eclipse, télécharger et importer BugBattle v0.4, qui est le point de départ pour ce laboratoire.

Il y aura plusieurs erreurs signalées par Eclipse parce que le cadre d’applications jUnit 4 ne se trouve pas dans le « build path » du projet. Afin de régler ce problème, ouvrez la classe AllTest, mettez le curseur sur la directive @RunWith, et choisissez l’option d’ajouter jUnit 4.

Exécutez la classe BugBattle afin de vous assurer qu’elle fonctionne. Exécutez la suite des tests jUnit dans la classe AllTests (Run As > jUnit test) et vérifiez que la barre jUnit est verte.

Familiarisation avec le code

Générez la documentation javadoc pour le projet dans Eclipse (Project > Generate Javadoc…). Lisez la documentation javadoc et le code source du projet jusqu’à ce que vous le compreniez.

Afin de vous aider à comprendre les classes de test, référez-vous à l’ API de jUnit, plus particulièrement la documentation pour le paquet org.junit. Le document jUnit 4 in 60 seconds vous sera peut-être utile.

Familiarisation avec la demande de modification

Lisez attentivement et au complet le document de demande de changement de BugBattle v0.5 avant de commencer les modifications.

Implémentation et documentation

Implémentez la demande de modifications

On vous demande d’utiliser une approche de développement piloté par les tests. Il n’est pas possible de vous forcer à travailler de cette façon, mais il est vraiment préférable d’écrire les tests en premier, de diviser le travail en petits incréments, d’écrire le nouveau code d’application avec une barre rouge (test qui échoue) et d’implémenter jusqu’à ce que vous ayez une barre verte.

À mesure que vous créez de nouveaux cas de test, ajoutez-les au groupe de tests (« test suite ») AllTest. Vous pouvez exécuter une classe de test à la fois ou tous les tests ensemble avec AllTest selon votre préférence. En pratique, il est normalement mieux d’exécuter tous les tests après chaque modification. Cette approche vous donne une indication immédiate si vous avez brisé quelque chose.

Écrivez du javadoc au fur et à mesure que vous ajoutez ou modifiez les classes, méthodes et attributs. Vous n’avez pas besoin de fournir du javadoc pour les classes de test, mais elles devraient s’expliquer d’elles-mêmes. Référez-vous aux classes de test fournies pour voir des exemples.

Documentation du design en UML

Fournissez des diagrammes de classe et de séquence qui documente uniquement les modifications faites dans cette version de BugBattle. Il n’est pas nécessaire de donner un diagramme de classe montrant tout le système, mais seulement les diagrammes de classe des parties modifiées. Utilisez aussi votre jugement pour déterminer quels diagrammes de séquence seraient utiles à la compréhension du fonctionnement de votre code.

Si nécessaire, incluez du texte explicatif avec vos diagrammes. Vous pouvez supposer que le lecteur a accès à votre code et javadoc. Ne répétez donc pas l’information qui est évidente.

Allocation des points

  • Rapport (incluant le UML): 15
  • Spikes: 21
  • SpikeyCreature: 11
  • PhotoGland: 15
  • Plant: 18
  • Croissance des Plant: 15
  • Retrait de l’énergie gratuite: 5
  • Sous-classes Creature intelligente: 25
Scroll to Top