Test de Jeu
Testez un jeu comme le ferait un ingénieur QA, en utilisant Claude Code ou une session de chat avec les fichiers du projet.
Workflow
- Lire les règles : ouvrez
RULES.mds'il existe (issu de la compétence game-rules-core). Sinon, déduisez les règles du code et écrivez-les d'abord. Les règles non testables sont des bugs du cahier des charges. - Cartographier le code : trouvez la boucle de jeu, la machine à états, la gestion des entrées, les collisions, l'apparition d'entités (spawn) et le code de score.
- Revue statique : parcourez les bugs courants listés dans
references/checklist.md. - Écrire des tests : testez unitairement la logique pure (mathématiques de collision, score, transitions d'état) et ajoutez un test de simulation déterministe si possible (seed fixe, dt fixe, entrées scriptées).
- Exécuter et observer : lancez les tests et, si un outil navigateur est disponible, jouez au jeu et capturez les erreurs console.
- Rapporter : rédigez
BUG_REPORT.mden utilisant le format ci-dessous.
Catégories de test (couvrir tout)
- Boucle principale : démarre, pause, reprend, redémarre, game over, victoire. Chaque transition d'état fonctionne et réinitialise les bonnes choses.
- Entrées : touches simultanées, touche maintenue pendant une pause, appuis rapides, perte de focus (blur), tactile et manette si supportés.
- Collision/physique : tunneling à haute vitesse, accrochage aux coins, se tenir sur les bords, plateformes mobiles, chute hors du monde.
- Règles : chaque ligne de
RULES.mda au moins un test : déclencheur, condition, effet, cas limite. - Score/progression : il s'incrémente correctement, pas de double comptage, se réinitialise au redémarrage, la persistance (localStorage) survit au rechargement et gère les données corrompues.
- Apparition (spawn) : limites respectées, toujours possible, aucune entité restante après redémarrage, aucune croissance mémoire dans le temps.
- Indépendance du taux de rafraîchissement : exécution simulée à 30, 60 et 144 FPS ; les résultats du jeu doivent correspondre.
- Performances : temps par image, nombre d'entités, fuites mémoire, appels de draw (3D).
- Robustesse : redimensionnement de fenêtre, changement d'onglet, redémarrage rapide, viewport mobile.
- Déterminisme : même seed et mêmes entrées donnent le même résultat.
Format du rapport de bugs
Pour chaque bug :
- ID / Titre
- Sévérité : Critique (crash, blocage logiciel, perte de progression) / Majeur (règle non respectée) / Mineur (visuel, ressenti) / Polish
- Étapes pour reproduire (numérotées, exactes)
- Attendu vs Réel
- Preuve : fichier et ligne, erreur console, ou nom du test en échec
- Correction suggérée (une ou deux lignes)
Terminez le rapport par un tableau récapitulatif (comptes par sévérité) et une liste de ce qui n'a PAS été testé.
Règles strictes
- Ne jamais signaler un bug sans preuve (un test en échec, un log, ou un chemin de code que vous pouvez pointer).
- Ne jamais affirmer que quelque chose fonctionne si vous ne l'avez pas exécuté ; dites "révisé, non exécuté".
- Préférez les tests déterministes à "j'y ai joué et ça m'a semblé correct".
- Ne modifiez pas le code du jeu sauf demande expresse ; signalez d'abord, corrigez sur demande.