comment automatiser les tests de jeu?

Je suis nouveau dans ce domaine des tests. Je viens de développer un jeu de base en utilisant le moteur d'unité mais je veux le tester.

J'ai vérifié avec du sélénium mais je ne sais pas comment obtenir la valeur renvoyée qui contient les informations de l'action qui est effectuée dans le jeu. Si je peux obtenir la valeur, je pourrai prendre les mesures nécessaires en conséquence.

Il existe plusieurs façons de tester un jeu, les deux plus utilisées sont: les tests unitaires et d'intégration.

Pour les tests unitairesvous testez le fonctionnement interne du jeu, sans le lancer. Vous pouvez le faire pour des modules spécifiques dont les dépendances sont abstraites (par exemple, la logique qui calcule le Quest XP que vous obtenez, en fonction d'un ensemble donné de facteurs; si un son donné est joué). En fonction de l'abstraction de votre logique, vous pouvez tester plus, mais pour l'unité en particulier, cela pourrait être plus difficile compte tenu de la façon dont l'architecture du jeu est réalisée (par exemple, hériter de monobehaviour). Néanmoins, en appliquant des modèles OOP comme la composition, vous pouvez extraire des bits de logique qui peuvent être testés de manière déterministe (par exemple, la physique), même si parfois cela peut être vu comme un peu extrême. Tout dépend du temps dont vous disposez, si vous avez commencé à zéro avec le projet ou non, de votre expérience, etc. En général, je n'ai pas t vu beaucoup de tests unitaires dans les jeux par rapport aux autres projets logiciels non-jeu. Ce type de test est assez facile à automatiser car vous fournissez des comportements simulés que vous simulez.

Pour les tests d'intégration , vous interagissez avec le jeu "entier" à un moment donné, lorsque toutes les parties sont en cours d'exécution. Selon la profondeur des choses que vous souhaitez tester, je vois que cela pourrait être très facile, voire carrément impossible.

Une idée serait d'avoir un build "test d'intégration", qui enregistre toutes les actions (la plupart) qu'il fait (c'est-à-dire le monstre qui se reproduit, le son qui joue, l'effet de démarrage, la particule qui se reproduit). Après qu'il s'exécute pendant un temps donné, vous pouvez vérifier les journaux pour voir s'il correspond à un modèle donné (cela dépend également de la façon dont le jeu est aléatoire, en fonction des entrées). Maintenant, cela semble simple, mais la question est: comment dire au jeu de faire les actions souhaitées? Ce qui m'amène à la deuxième idée.

Une autre idée serait d'avoir un type de serveur dans le jeu, encore une fois, à des fins de test, qui est capable de traiter les demandes (par exemple, via une API REST), et qui agit sur les entités. Les demandes peuvent être des choses comme: se déplacer vers la gauche, sauter, faire pivoter X degrés, changer de fenêtre, etc. journal des événements qui se sont produits. Cette approche est utilisée par d'autres outils de test de l'interface utilisateur pour les mobiles (par exemple, Xamarin Test Cloud)

Pour la partie contrôle, si votre jeu est basé sur le toucher / navigateur, vous pouvez à la place simuler les actions via un dispositif tactile / d'entrée virtuel, mais cela est un peu plus difficile, selon la complexité des actions.

Une autre idée, en ce qui concerne l'aspect visuel, est de prendre des captures d'écran de référence, des images pendant une phase initiale, et de les comparer après que la même séquence d'action s'est produite sur une version plus récente. La comparaison peut avoir une allocation d'écart spécifique, pour se prémunir contre des changements mineurs. Pendant les tests, vous pouvez enregistrer les écrans qui ne correspondent pas et voir la différence. Il se peut que les écrans de référence doivent être mis à jour en raison de changements différents. Dans ce cas, le jeu pourrait être exécuté à nouveau avec les actions prédéfinies et les images de référence mises à jour. Cela ne fonctionnera probablement pas très bien avec des systèmes de particules ou des scènes générées de manière aléatoire, sauf si vous utilisez l'idée précédente pour définir une sorte de graine, qui est utilisée pour générer les particules.

Pour les sons, cela peut être un peu plus dur, car cela impliquera une "écoute" du périphérique OUT (ce qui n'est pas toujours possible IIRC, car cela dépend du matériel du système). Mais si c'est possible, vous pouvez faire la même comparaison basée sur les références que vous faites avec les images.

J'espère que cela vous éclairera sur la façon d'automatiser les tests de jeu.

Édition ultérieure: je vois juste qu'il y avait une autre question connexe qui pourrait vous donner quelques conseils sur la façon dont vous feriez certains bits: Test automatisé des jeux