Identifier les entrées incontrôlées
Répertoriez tout ce qui peut varier d'une exécution à l'autre : positions aléatoires de l'ennemi, temps écoulé, synchronisation des images d'animation, score élevé enregistré, dimensions de la fenêtre d'affichage et séquence d'entrées utilisateur. Décidez quelles variables sont importantes pour le comportement testé. Pour un contrôle de collision, utilisez un emplacement ennemi fixe et un départ de joueur connu. Pour une vérification du modèle d'apparition, contrôlez la séquence aléatoire mais testez plusieurs graines sélectionnées afin qu'une configuration ne cache pas un mauvais modèle.
Contrôlez le temps sans figer le comportement des joueurs
Pour une règle de minuterie, fournissez une heure de début explicite et vérifiez ce qui se passe à une limite significative, par exemple trois secondes restantes et exactement zéro. Pour les mouvements basés sur des images, comparez la même durée écoulée au lieu du même nombre d'images rendues. MDN note que la fréquence de rappel de requestAnimationFrame suit généralement la fréquence de rafraîchissement de l'affichage et que les rappels sont suspendus dans la plupart des navigateurs pour les onglets masqués ; le code d'animation doit donc utiliser son horodatage ou une autre source de temps lors du calcul de la progression.
Questions sur tests de jeux déterministes
Les tests déterministes signifient-ils supprimer le gameplay aléatoire ?
Non. Cela signifie contrôler le caractère aléatoire de tests sélectionnés pour comparer les comportements. Vous pouvez toujours exécuter des tests exploratoires distincts sur des graines variées pour inspecter la gamme du jeu.
Pourquoi un test peut-il réussir localement et échouer dans un navigateur ?
Différents timings, fenêtres d'affichage, états enregistrés ou séquences aléatoires peuvent modifier la configuration. Enregistrez ces conditions et contrôlez celles pertinentes pour le comportement vérifié.
Pour aller plus loin
Vous avez repéré une information dépassée ? Signaler une correction