Tests automatisés de jeux : combiner vérifications headless et preuves de rendu

Choisir les preuves nécessaires

Un build de jeu peut se lancer sans erreur alors qu'une migration de sauvegarde fait perdre l'inventaire ou qu'un shader affiche mal un personnage. Définissez pour chaque test le défaut qu'il doit détecter. Utilisez des vérifications ciblées pour les règles du jeu, des tests d'intégration pour les systèmes qui interagissent et des vérifications de rendu pour le comportement visuel. Le framework d'automatisation d'Unreal distingue les tests unitaires, les tests de fonctionnalités, les tests de charge sur le contenu et les tests par capture d'écran. [2] La réussite d'une catégorie ne prouve pas que les autres sont couvertes.

Rendre l'exécution sans surveillance observable

L'interface en ligne de commande de Godot permet l'exécution headless, le lancement de scripts de projet et une opération d'import qui attend la fin de l'import des ressources avant de quitter. [1] Un projet peut s'appuyer sur ces éléments pour construire un exécuteur de tests sans surveillance. Faites en sorte que cet exécuteur renvoie un code de sortie d'échec lorsqu'une assertion échoue et qu'il conserve un rapport structuré.

Lors de la mise en place, vérifiez le chemin d'échec avec une fixture volontairement défaillante. Sinon, un job peut sembler réussir simplement parce qu'il a lancé un projet vide, ignoré une option non prise en charge ou jamais exécuté les vérifications prévues. Une exécution headless réussie ne prouve pas à elle seule que le GPU cible produit des pixels corrects.

Exemple d'une petite suite

Pour un jeu d'action servant d'illustration, prévoyez 20 tests de règles ciblés, quatre vérifications de scène et trois fixtures de rendu. Les tests de règles peuvent porter sur la capacité de l'inventaire et sur les conditions d'application des dégâts. Les vérifications de scène peuvent exercer l'apparition des entités, la restauration d'un point de contrôle, une transition par une porte et une déconnexion provoquée. Les fixtures de rendu peuvent contenir une surface avec normal mapping, des particules transparentes et une transition d'éclairage du sombre au lumineux.

Réinitialisez chaque fixture indépendamment. Enregistrez les graines aléatoires, les ticks de simulation, les versions des assets et les entrées pertinentes. Rejouer un enregistrement aide à reproduire les échecs, mais une graine fixe ne garantit pas à elle seule une simulation identique d'une plateforme à l'autre. Ces chiffres décrivent une suite proposée, et non des tests réellement menés sur un jeu existant.

Maîtriser les comparaisons de captures d'écran

Fixez la caméra, la résolution, le moteur de rendu, l'exposition et le moment de la capture. Utilisez un job disposant d'un GPU pour la configuration de rendu visée. L'outil de capture d'écran d'Epic propose des tolérances par canal ainsi que des seuils d'erreur locaux et globaux, ce qui reflète le fait que certains rendus présentent des variations. [3]

Conservez ensemble l'image de référence, la nouvelle image et l'image de différence. Une faible erreur globale peut masquer un défaut local flagrant, comme un œil ou une icône d'interface manquants. Choisissez les seuils en fonction du défaut testé et examinez les modifications d'images de référence comme des modifications de contenu. Remplacer automatiquement chaque image de référence en échec effacerait la preuve apportée par le test.

Préserver l'utilité de la suite

Exécutez souvent les vérifications rapides et stables, et réservez les passes coûteuses sur les plateformes ou le contenu à une planification adaptée. Isolez les fichiers générés et ne supposez pas qu'un autre test a laissé le monde dans un état exploitable. [2] Dans les rapports, distinguez les défaillances d'infrastructure des assertions de jeu en échec.

Analysez les tests instables plutôt que d'augmenter systématiquement les délais d'expiration ou les tolérances d'image. Conservez la plus petite scène et la plus courte séquence d'entrées qui expliquent un échec. L'automatisation permet une vérification reproductible ; les sessions de playtest apportent toujours des éléments sur les sensations de jeu, la lisibilité et les situations que la suite n'a jamais modélisées.

Sources

[1] Godot command line tutorial — Godot Engine contributors.

[2] Automation Test Framework — Epic Games.

[3] Screenshot Comparison Tool — Epic Games.