Dans le développement de jeux, les tests manuels peuvent rapidement devenir répétitifs et sujets à des erreurs. Vous êtes-vous déjà retrouvé dans l'un de ces cycles de test apparemment interminables lorsque vous travaillez sur une nouvelle fonctionnalité ou essayez de corriger un bug ?
En automatisant vos tests de code, vous pouvez passer plus de temps sur le développement de jeux créatifs et moins sur les tâches répétitives (mais importantes) d'assurance qualité, ce qui garantit que l'ajout, la suppression ou la modification de code ne rompt pas votre projet.
Unity vous aide à créer, gérer et exécuter des tests automatisés pour vos jeux grâce à Unity Test Framework .
Unity Test Framework (UTF) vous permet de tester le code de votre projet à la fois en mode Édition et en mode Lecture. Vous pouvez également cibler le code de test pour diverses plateformes telles que les plateformes autonomes, iOS ou Android .
UTF est installé en l'ajoutant à votre projet avec le Package Manager.
Sous le capot, UTF s'intègre à NUnit, une bibliothèque de tests open source réputée pour les langages .NET.
Il existe deux grandes catégories de tests que vous pouvez écrire avec UTF, le mode Edit et le mode Play :
Les tests en mode édition s'exécutent dans l'éditeur Unity et ont accès à l'éditeur et au code du jeu. Cela signifie que vous pouvez tester vos extensions personnalisées de l'éditeur ou utiliser des tests pour modifier les paramètres dans l'éditeur et entrer en mode lecture, ce qui est utile pour ajuster les valeurs Inspector, puis exécuter des tests automatisés avec de nombreux paramètres différents.
Les tests en mode lecture vous permettent d'exercer votre code de jeu lors de l'exécution. Les tests sont généralement exécutés sous forme de co-programmes à l'aide de l'attribut [UnityTest]. Cela vous permet de tester du code qui peut s'exécuter sur plusieurs images. Par défaut, les tests en mode lecture seront exécutés dans l'éditeur, mais vous pouvez également les exécuter dans une compilation de joueur autonome pour diverses plateformes cibles.
Pour suivre cet exemple, vous devrez installer le package Starter Assets – Third Person Character Controller depuis l’Asset Store Unity et l’importer dans un nouveau projet.
Installez UTF via Window > Package Manager. Recherchez Test Framework dans le registre Unity du Package Manager. Assurez-vous de sélectionner la version 1.3.3 (la dernière version au moment de la rédaction du présent rapport).
Une fois UTF installé, ouvrez le fichier Packages/manifest.json avec un éditeur de texte et ajoutez une section testables après les dépendances, comme ceci :
,
"testables": [
"com.unity.inputsystem"
]
Enregistrez le fichier. Cela vous sera utile ultérieurement, lorsque vous aurez besoin de référencer l'assemblage Unity.InputSystem.TestFramework pour tester et émuler les entrées des joueurs.
Retournez dans l'éditeur et autorisez l'installation de la nouvelle version.
Cliquez sur Window > General > Test Runner pour afficher la fenêtre de l'éditeur Test Runner .
Dans cette partie du tutoriel, l'accent sera mis sur la création de tests en mode lecture. Plutôt que d'utiliser les options Créer un dossier d'assemblage de test dans la fenêtre Test Runner, vous les créerez à l'aide de la fenêtre Projet.
Avec la racine de votre dossier Project Assets en surbrillance, faites un clic droit et choisissez Créer > Tester > Tests Assembly Folder.
Un dossier de projet Tests est ajouté, contenant un fichier Tests.asmdef (définition de l'assemblage). Ceci est obligatoire pour les tests afin de référencer vos modules de jeu et vos dépendances.
Le code du contrôleur de personnage sera référencé dans les tests et aura également besoin d'une définition d'assemblage. Ensuite, vous définirez des définitions et des références d'assemblage pour faciliter les tests entre les modules.
Cliquez avec le bouton droit sur le dossier de projet Assets/StarterAssets/InputSystem, puis choisissez Créer > Définition d'assemblage. Donnez-lui un nom descriptif, par exemple StarterAssetsInputSystem.
Sélectionnez le nouveau fichier StarterAssetsInputSystem.asmdef et, à l'aide de l'Inspector, ajoutez une référence de définition d'assemblage à Unity.InputSystem. Cliquez sur Appliquer.
Cliquez avec le bouton droit sur le dossier de projet Asset/StarterAssets/ThirdPersonController/Scripts, puis choisissez Create > Assembly Definition. Donnez-lui un nom descriptif, par exemple ThirdPersonControllerMain.
Comme vous l'avez fait avec la définition d'assemblage précédente, ouvrez ThirdPersonControllerMain dans l'Inspector et sélectionnez des références pour :
- Unity.InputSystem
- StarterAssetsInputSystem
Cliquez sur Appliquer.
Pour imiter des parties du système d'entrée, vous devrez y faire référence dans vos tests. En outre, vous devrez référencer l'espace de noms StarterAssets dans un assemblage que vous créerez pour le code du contrôleur à la troisième personne.
Ouvrez Tests.asmdef dans l'Inspector et ajoutez une référence aux définitions d'assemblage suivantes :
- UnityEngine.TestRunner
- UnityEditor.TestRunner
- Unity.InputSystem
- Unity.InputSystem.TestFramework
- ThirdPersonControllerMain
Cliquez sur Appliquer.
Votre premier test abordera les bases du chargement et du déplacement du personnage principal à partir du package Third Person Controller.
Commencez par configurer le nouveau projet avec une scène d'environnement de test simple et une ressource Prefab de personnage à utiliser.
Ouvrez la scène nommée Assets/StarterAssets/ThirdPersonController/Scenes/Playground.unity et enregistrez-en une copie à l'aide du menu Fichier > Enregistrer sous sur ce nouveau chemin : Asset/Scènes/SimpleTesting.unity
Si vous remarquez des matériaux roses dans la fenêtre Game, utilisez le convertisseur du pipeline de rendu pour mettre à niveau les matériaux du pipeline de rendu intégré vers le pipeline de rendu universel (URP). Consultez cet article pour un aperçu rapide.
Créez un nouveau dossier intitulé Ressources dans votre dossier Project Assets. Remarque : Le nom du dossier «Resources» est important ici pour permettre l'utilisation de la méthode Unity Resources.Load() .
Faites glisser et déposez le GameObject PlayerArmature dans la fenêtre Scene dans le nouveau dossier Resources, et choisissez de créer un prefab original lorsque vous y êtes invité. Renommez le personnage de ressource prefab.
Il s'agira du prefab du personnage de base utilisé dans vos tests à venir.
Supprimez le GameObject PlayerArmature de la nouvelle scène SimpleTesting et enregistrez les modifications apportées à la scène.
Pour la dernière étape de la configuration initiale du test, accédez à Fichier > Paramètres de compilation, puis choisissez Ajouter des scènes ouvertes pour ajouter la scène Scènes/SimpleTesting aux paramètres de compilation.
Sélectionnez le dossier Tests dans le dossier Project Assets. Faites un clic droit et choisissez Créer > Testing > C# Test Script.
Nommez les nouveaux Script CharacterTests. Ouvrez le script dans votre IDE pour l'examiner de plus près.
Deux talons de méthode sont fournis avec le fichier de classe initial, démontrant certaines bases du test.
Ensuite, vous vous assurerez que les tests chargent une scène de jeu « axée sur les tests ». Cette scène doit contenir le strict minimum requis pour tester le système ou le composant sur lequel vous vous concentrez.
Mettez à jour la classe CharacterTests pour ajouter deux nouvelles instructions à l'aide et implémentez la classe InputTestFixture :
using UnityEngine.InputSystem;
utiliser UnityEngine.SceneManagement ;
public class CharacterTests : InputTestFixture
Ajoutez deux champs privés en haut de la classe CharacterTests :
GameObject character = Resources.Load("Caractère");
Clavier;
Le champ personnage stockera une référence au prefab personnage, chargé à partir du dossier Ressources. Le clavier contient une référence au périphérique d'entrée du clavier fourni par l'InputSystem.
Remplacez la méthode Setup() de la classe de base InputTestFixture en fournissant la vôtre dans la classe CharacterTests :
public override void Setup()
{
SceneManager.LoadScene("Scenes/SimpleTesting");
base.Setup();
keyboard = InputSystem.AddDevice();
var mouse = InputSystem.AddDevice();
Appuyez sur(mouse.rightButton);
Release(mouse.rightButton);;
}
La méthode Setup() exécute la méthode Setup() de la classe de base, puis configure votre propre classe CharacterTests en chargeant la scène de test et en initialisant le périphérique d'entrée clavier.
L'entrée de la souris est ajoutée uniquement pour que le contrôleur à la troisième personne commence à recevoir l'entrée de l'appareil à clavier virtuel/simulé. Cela ressemble presque à une action de « mise au point ».
Pour votre premier test, vous instancierez le personnage du prefab et affirmerez qu'il n'est pas null . Ajoutez la méthode suivante à votre classe de test :
[Test]
public void TestPlayerInstantiation()
{
GameObject characterInstance = GameObject.Instantiate(character, Vector3.zero, Quaternion.identity);
Assert.That(characterInstance, !Is.Null);
}
Tant que vous y êtes, vous devriez peut-être nettoyer l'exemple de méthodes de test du modèle. Supprimez les méthodes CharacterTestsSimplePasses et CharacterTestsWithEnumeratorPasses.
Enregistrez le script et retournez à la fenêtre Test Runner dans l'éditeur. Mettez en surbrillance le test TestPlayerInstanciation et cliquez sur Exécuter sélectionné.
La coche verte signifie un examen réussi. Vous avez affirmé que le personnage peut être chargé à partir de ressources, instancié dans la scène de test et n'est pas null à ce moment-là.
Vous avez peut-être remarqué que l'annotation [Test] a été utilisée pour ce test au lieu de l'annotation [UnityTest]. L'attribut UnityTest permet aux co-programmes d'exécuter des tests sur plusieurs images. Dans ce cas, vous devez juste instancier le personnage et affirmer qu'il a été chargé.
En règle générale, vous devez utiliser l'attribut NUnit Test au lieu de l'attribut UnityTest en mode Édition, à moins que vous ayez besoin de donner des instructions spéciales, de sauter une image ou d'attendre un certain temps en mode Lecture.
Ensuite, vous utiliserez UnityTest car vous affirmez qu'en maintenant la touche de contrôleur enfoncée, le personnage avance.
Ajoutez la nouvelle méthode de test fournie ci-dessous à votre classe CharacterTests.
Deux nouvelles méthodes d'aide au test sont apparues : Press() et Release(). Ceux-ci sont fournis par la classe de base InputTestFixture et vous aident en émulant la pression et la libération du contrôle InputSystem.
La méthode TestPlayerMoves() effectue les opérations suivantes :
Instancie une instance du personnage à partir du prefab du personnage à l'emplacement (X : 0, Y : 0, Z : 0)
Appuyez sur la touche fléchée vers le haut du clavier virtuel pendant 1 seconde, puis relâchez-la
Attend 1 seconde de plus (pour que le personnage ralentisse et cesse de bouger)
Indique que le personnage s'est déplacé dans une position sur l'axe Z supérieure à 1,5 unité.
Enregistrez le fichier, revenez au Test Runner et exécutez le nouveau test.
Ensuite, vous testerez un script MonoBehaviour personnalisé en ajoutant un simple composant Player Health.
Créez un nouveau script sous Asset/StarterAssets/ThirdPersonController/Scripts. Appelez-le PlayerHealth.
Ouvrez le script dans votre IDE et remplacez le contenu par le code fourni ci-dessous.
Il y a beaucoup de nouveaux codes ajoutés ici. Pour résumer, ce script déterminera si le personnage du joueur est dans un état décroissant. Si le sol est touché une fois dans un état de chute, les points de vie du personnage sont réduits de 10 %.
Localisez le prefab Personnage sous Asset/Ressources. Ouvrez le prefab et ajoutez le nouveau composant de script PlayerHealth.
Ensuite, vous utiliserez la scène de test pour affirmer que les points de vie du joueur baissent après être tombé d'un rebord.
À l'aide de l'attribut [UnityTest], vous pouvez rédiger un test en mode lecture qui teste les dommages causés par les chutes. Lorsqu'il tombe pendant plus de 0,2 seconde, le joueur doit subir 0,1f de dégâts (l'équivalent de 10% du maximum de points de vie).
Dans la scène de SimpleTesting, vous verrez un escalier menant à un rebord. Il s'agit d'une plateforme de test pour générer le personnage et tester le script PlayerHealth.
Ouvrez à nouveau CharacterTests.cs et ajoutez une nouvelle méthode de test nommée TestPlayerFallDamage :
[UnityTest]
IEnumérateur public TestPlayerFallDamage()
{
// fait apparaître le personnage dans une zone assez haute dans la scène de test
GameObject characterInstance = GameObject.Instantiate(personnage, nouveau vecteur3(0f, 4f, 17.2f), Quaternion.identity);
// Obtenez une référence au composant PlayerHealth et affirmez qu'il est actuellement en pleine santé (1f)
var characterHealth = characterInstance.GetComponent();
Assert.That(characterHealth.Health, Is.EqualTo(1f));
// Sortez du rebord et attendez la chute
Appuyez sur(keyboard.upArrowKey);
retour de rendement nouveau WaitForSeconds(0.5f);
Release(keyboard.upArrowKey);
yield return new WaitForSeconds(2f);
// Indiquer qu'un point de vie a été perdu à cause des dégâts causés par la chute
Assert.That(characterHealth.Health, Is.EqualTo(0.9f));
}
Vous devrez également ajouter une référence à l'aide de l'espace de noms StarterAssets tout en haut du fichier de classe :
utiliser StarterAssets ;
Le test ci-dessus suit un schéma AAA typique, couramment utilisé lors des tests :
La section Assert vérifie que l'action de la méthode testée se comporte comme prévu.
Ensuite, vous testerez un script MonoBehaviour personnalisé en ajoutant un simple composant Player Health.
Créez un nouveau script sous Asset/StarterAssets/ThirdPersonController/Scripts. Appelez-le PlayerHealth.
Ouvrez le script dans votre IDE et remplacez le contenu par le code fourni ci-dessous.
Il y a beaucoup de nouveaux codes ajoutés ici. Pour résumer, ce script déterminera si le personnage du joueur est dans un état décroissant. Si le sol est touché une fois dans un état de chute, les points de vie du personnage sont réduits de 10 %.
Localisez le prefab Personnage sous Asset/Ressources. Ouvrez le prefab et ajoutez le nouveau composant de script PlayerHealth.
Ensuite, vous utiliserez la scène de test pour affirmer que les points de vie du joueur baissent après être tombé d'un rebord.
À l'aide de l'attribut [UnityTest], vous pouvez rédiger un test en mode lecture qui teste les dommages causés par les chutes. Lorsqu'il tombe pendant plus de 0,2 seconde, le joueur doit subir 0,1f de dégâts (l'équivalent de 10% du maximum de points de vie).
Dans la scène de SimpleTesting, vous verrez un escalier menant à un rebord. Il s'agit d'une plateforme de test pour générer le personnage et tester le script PlayerHealth.
Ouvrez à nouveau CharacterTests.cs et ajoutez une nouvelle méthode de test nommée TestPlayerFallDamage :
[UnityTest]
IEnumérateur public TestPlayerFallDamage()
{
// fait apparaître le personnage dans une zone assez haute dans la scène de test
GameObject characterInstance = GameObject.Instantiate(personnage, nouveau vecteur3(0f, 4f, 17.2f), Quaternion.identity);
// Obtenez une référence au composant PlayerHealth et affirmez qu'il est actuellement en pleine santé (1f)
var characterHealth = characterInstance.GetComponent();
Assert.That(characterHealth.Health, Is.EqualTo(1f));
// Sortez du rebord et attendez la chute
Appuyez sur(keyboard.upArrowKey);
retour de rendement nouveau WaitForSeconds(0.5f);
Release(keyboard.upArrowKey);
yield return new WaitForSeconds(2f);
// Indiquer qu'un point de vie a été perdu à cause des dégâts causés par la chute
Assert.That(characterHealth.Health, Is.EqualTo(0.9f));
}
Vous devrez également ajouter une référence à l'aide de l'espace de noms StarterAssets tout en haut du fichier de classe :
utiliser StarterAssets ;
Le test ci-dessus suit un schéma AAA typique, couramment utilisé lors des tests :
La section Arrange d'une méthode de test unitaire initialise les objets et définit la valeur des données qui sont transmises à la méthode en test.
La section Act invoque la méthode à l'essai avec les paramètres arrangés. Dans ce cas, l'invocation de la méthode à l'essai est gérée par une interaction physique lorsque le joueur touche le sol après être tombé.
La section Assert vérifie que l'action de la méthode testée se comporte comme prévu.
De retour dans l'éditeur, exécutez le nouveau test. Exécution en mode lecture, vous verrez le personnage quitter le bord, tomber (dépassant le seuil de 0,2 seconde pour catégoriser une chute) et subir des dommages après avoir touché le sol.
Les tests ont non seulement pour but de vérifier que les changements de code ne rompent pas les fonctionnalités, mais ils peuvent également servir de documentation ou de pointeurs pour aider les développeurs à réfléchir à d'autres aspects du jeu lors de l'ajustement des paramètres.
Comme mentionné précédemment, l'exécution par défaut des tests en mode lecture dans le Test Runner les exécute en mode lecture à l'aide de l'éditeur Unity. Vous pouvez également les modifier pour qu'ils fonctionnent sous un lecteur autonome.
Utilisez la sélection déroulante Exécuter l'emplacement dans la fenêtre Test Runner pour changer de test afin de l'exécuter dans les compilations de joueur autonome.
Une fois que vous avez commencé à créer une suite de tests, l'étape suivante consiste à les exécuter automatiquement une fois les compilations terminées. Les tests unitaires et d'intégration automatisés qui s'exécutent après la compilation sont utiles pour détecter les régressions ou les bugs dès que possible. Ils peuvent également s'exécuter dans le cloud en tant qu'élément d'un système de compilation automatisé à distance.
Souvent, vous aurez envie de capturer les résultats des tests dans un format personnalisé afin qu'ils puissent être partagés avec un public plus large. Afin de capturer les résultats des tests en dehors de l'éditeur Unity, vous devrez scinder les processus de compilation et d'exécution.
Créez un nouveau script dans votre dossier de projet Tests nommé SetupPlaymodeTestPlayer.
La classe SetupPlaymodeTestPlayer implémentera l'interface ITestPlayerBuildModifier. Vous l'utiliserez pour remplacer et « accrocher » la méthode ModifyOptions, qui reçoit les options de lecteur de la compilation et vous permet de les modifier.
utiliser System.IO;
utiliser UnityEditor ;
using UnityEditor.TestTools;
[assemblage : TestPlayerBuildModifier(typeof(SetupPlaymodeTestPlayer))]
public class SetupPlaymodeTestPlayer : ITestPlayerBuildModifier
{
public BuildPlayerOptions ModifyOptions(BuildPlayerOptions playerOptions)
{
playerOptions.options &= ~(BuildOptions.AutoRunPlayer | BuildOptions.ConnectToHost);
var buildLocation = Path.GetFullPath("TestPlayers");
var fileName = Path.GetFileName(playerOptions.locationPathName);
if (!string.IsNullOrEmpty(fileName))
buildLocation = Path.Combine(buildLocation, fileName);
playerOptions.locationPathName = buildLocation;
retour du joueurOptions ;
}
}
Ce script de modification personnalisé Player Build effectue les opérations suivantes lorsque les tests sont exécutés en mode lecture (Emplacement d'exécution : Sur le lecteur) :
Désactive l'exécution automatique pour les joueurs créés et saute l'option du joueur qui tente de se connecter à l'hôte sur lequel il est exécuté
Change l'emplacement du chemin de compilation pour un chemin dédié dans le projet (TestPlayers)
Avec cette version complète, vous pouvez désormais vous attendre à ce que les compilations se trouvent dans le dossier TestPlayers à chaque fois qu'elles finissent de compiler. Ceci complète désormais les modifications de compilation et coupe le lien entre compilation et exécution.
Ensuite, vous mettrez en place un rapport de résultats. Cela vous permettra de rédiger les résultats des tests dans un emplacement personnalisé, prêt pour la génération et la publication automatisées de rapports.
Créez un nouveau script dans votre dossier de projet Tests nommé ResultSerializer (fourni ci-dessous). Cette classe utilisera une référence d'assemblage à TestRunCallback et implémentera l'interface ITestRunCallback.
Cette implémentation d'ITestRunCallback inclut une méthode personnalisée RunFinished, qui configure une compilation de joueur avec des tests pour écrire les résultats du test dans un fichier XML nommé testsults.xml.
Avec SetupPlaymodeTestPlayer.cs et ResultSerializer.cs combinés, les processus de compilation et d'exécution sont désormais séparés. L'exécution des tests affichera les résultats sur teststresults.xml situé sur l'emplacement Application.persistentDataPath de la plateforme du joueur.
Pour utiliser certains des types de ces classes de hooks, vous devrez ajouter une référence supplémentaire à Tests.asmdef. Mettez-le à jour pour ajouter la référence de définition d'assemblage UnityEditor.UI.EditorTests.
Exécuter les tests dans le lecteur produira désormais une compilation de lecteur sous votre projet dans le dossier TestPlayers et un fichier testresults.xml dans l'emplacement Application.persistentDataPath.
Cours Unity Test Framework
Le package Test Framework comprend un cours comprenant des exemples d'exercices pour vous aider à en apprendre plus sur les tests avec Unity. Assurez-vous de sélectionner les fichiers du projet pour le cours à l'aide du Package Manager.
Utilisation de Package Manager > Packages : Unity Registry > Test Framework, localisez la liste déroulante Samples et importez les exercices du cours.
Les exercices seront importés dans votre projet et situés sous Asset/Samples/Test Framework . Chaque exemple comprend un dossier d'exercices sous lequel vous pouvez travailler, ainsi qu'une solution pour comparer votre propre travail au fur et à mesure.
QR votre code avec UTF
Cette intervention Unite Copenhagen sur UTF est plus détaillée et propose d'autres cas d'utilisation intéressants pour la personnalisation des tests. N'oubliez pas de le consulter pour voir ce qui est possible d'autre.
Le débogage dans Unity
Accélérez votre flux de production de débogage dans Unity grâce à des articles sur :
- Microsoft Visual Studio 2022
- Microsoft Visual Studio Code
E-books techniques avancés
Unity fournit un certain nombre de guides avancés pour aider les développeurs professionnels à optimiser le code du jeu. Créez un guide de style C# : Rédigez un code plus propre et adaptable et compilez les conseils d'experts du secteur sur la façon de créer un guide de style de code pour aider votre équipe à développer une base de code propre, lisible et adaptable.
Plus de 70 astuces pour améliorer la productivité avec Unity sont un autre guide populaire auprès de nos utilisateurs. Il regorge de conseils pour gagner du temps et améliorer votre flux de production quotidien grâce au LTS pour Unity 2020. Vous y trouverez également des conseils que même les développeurs expérimentés auraient pu manquer.
Documentation
Explorez plus en détail la dernière API TestRunner, découvrez d'autres attributs personnalisés UTF et découvrez d'autres cycles de vie auxquels vous pouvez vous connecter avec la documentation UTF.
Trouvez tous les ebooks et articles avancés de Unity dans le hub des bonnes pratiques Unity.
