Évaluation
Etudiant
Elbert NYUNTING
Avis global
7/20
Travail insuffisant, les consignes n’ont pas bien été lues, et à ma connaissance aucun bug n’a été trouvé/corrigé. Les suites de tests n’étaient pas suffisantes, et les métriques en témoignent.
Problème technique : maven était incapable d’exécuter les tests ! La commande mvn test
ne produisait donc rien. C’est pour cela que Jacoco ne fonctionnait pas.
La cause se trouve dans le nom des classes de test, qui ne se terminaient pas par "Test" Or, je cite le cours :
Toutes les classes dont le nom se termine par Test et contenant des méthodes de test (@Test) sont détectées dans le classpath Java et sont mémorisées.
Testabilité
Pas d’analyse par facteur, c’est dommage.
-
Observabilité : OK
-
Stabilité : Voir plus bas.
-
Controlabilité : Quid de CLI ? Du random ?
-
Changements nécessaires : OK pour getters et setters.
Le jeu n’utilise pas de fonctions aléatoires
Ah bon ?! Et pourtant il y a un random !
Tables de décision
Pourquoi moveNextPawn
et non move
? Choix surprenant.
-
Où sont les tables demandées ?
-
Plutôt bonne compréhension des entrées/sorties via l’objet appelant "this", mais cela ne suffit pas.
isGameOver
Nous avons donc deux types de classes d’équivalence: le nombre de pawns, et le nombre de gold.
Ce sont des données d’entrée, et non des classes d’équivalence.
-
Mais il manque des intervalles : quid d’un nombre de pawns inférieur à 1 ?
-
Et pour tes différentes entrées, tu ne considères qu’un domaine à la fois, pourquoi ?
Entrée : gold en jeu = [0, 2], sortie : game over = false
Et si on a 0 gold et 1 seul pawn ?
moveNextPawn
Il semble manquer pas mal de détails :
-
Pourquoi un cas où y < 0, et pas de cas où x < 0 ? Et quid des cas où x ou y sont supérieurs à la largeur/longueur du Board ?
-
Et faut-il tester des mouvements dans les différentes directions ?
-
Et différents cas lorsque attaque ou non ?
-
Et quid de l’attribut
currentPawn
comme entrée ?
Autres commentaires
CLIMain ne contient seulement la partie main qui sera exécuté lors du déroulement du jeu, et n’est dont pas intéressant de tester (car le but est de tester ce que cette classe appelera).
Mais pourtant CLIMain contient un algorithme central au fonctionnement du jeu, si un bug s’y trouve cela ne compromettrait-il pas tout le jeu ?
La classe OutOfBoardException est une classe d’exception et ne contient que l’ID de la version et ce que l’exception affichera. La classe StringColoring ne contient que les couleurs à afficher lors du jeu.
Mais est-ce que ces classes ont des instructions ? Et ces instructions pourraient-elles contenir des défauts ?
La classe Direction n’est qu’une énumération des direction des pions.
OK en effet, pas de code ici à tester.
CFGs
Aucun CFG.
Couverture code
Jacoco ne fonctionnait pas, comme indiqué au plus haut.
CLIMain pas couvert
Mutation
OK, mais peu de mutants tués.
CLIMain pas couvert
Suite de tests
Tests bien annotés ?
Non
Un test == un scénario ?
Non
Qualité du code de test ? (assertions etc)
-
Assertions bien utilisées
-
Isolation des tests améliorable (car trop de scénarios par méthode)
-
Tests insuffisants, notamment pour Pawn
Bugs trouvés
Aucun ?
-
La couleur bleue était renvoyée à la place de la couleur noire: non
-
2 hitpoints au lieu de 6: non
-
Les pions peuvent aller et exister en dehors du plateau : non
-
Les lettres attribués aux pions commencent à B au lieu de A : non
-
Un pion ne peut pas se déplacer alors qu’il le devrait : non
-
Il n’y a qu’un bonus sur la grille : non
-
La méthode isDead de la classe Pawn renvoit true quand le pion a -1 hitpoint : non
-
Code mort dans le toString de Board (
result += '|';
) : non -
Code mort dans attack (return "";) : non
-
Parfois pawn non ajouté car même coordonnées qu’un pawn existant : non
-
0/9
Rapport (forme / consignes)
Ecriture / lisibilité / structure
Manque flagrant de relecture, et asciidoc mal mis en forme.
Nombre de cas de tests ajoutés à chaque phase
Pas mentionné.
Couverture de code atteinte
Pas mentionné.
Score de mutation
OK
Liste des bugs
Pas mentionné.