Ce que vous trouverez sur cette page : des conseils sur l’utilisation de Unity Test Framework (UTF) pour l’assurance qualité de vos projets. UTF est l’un des outils d’assurance qualité les plus performants. Il permet exécuter des tests automatisés à la fois dans l’éditeur et sur des plateformes prises en charge. Et il est disponible pour tous les utilisateurs Unity !
Une nouvelle API Test Runner apporte davantage de flexibilité et d’extensibilité à UTF, pour la plupart de vos besoins de test. UTF est disponible via le Package Manager Unity, ce qui nous permet de transmettre les correctifs et les mises à jour plus rapidement. Cela signifie aussi que vous pouvez accéder localement au code source de UTF, le consulter, le parcourir lors du débogage et le modifier.
Pour en savoir plus, regardez la présentation de l'UTF à l'Unite Copenhagen, animée par Richard Fine et Christian Warnecke, développeurs de tests et d’outils Unity.

Premiers pas avec Unity Test Framework
If you are new to the Unity Test Framework (UTF), read the documentation for an introduction. In brief, the UTF enables Unity users to test their code in both Edit Mode and Play Mode, and also on target platforms such as Standalone, Android, iOS, and others.
UTF uses a Unity integration of the NUnit library, which is an open-source unit testing library for .Net languages. For more information about NUnit, see the official NUnit website and the NUnit documentation on GitHub.
You might also find these blog posts informative:
Performance benchmarking in Unity: How to get started
Testing test-driven development with the Unity Test Runner
Another related solution to learn about is Backtrace, an error management platform that enables you to capture crashes and exceptions and fix them quickly. Watch this Unite Now session for an in-depth introduction.
Présentation de l’API Test Runner
Vous pouvez exécuter vos tests par programme à partir de tout script via l’API Test Runner (voir API ci-dessous). Elle vous permet de récupérer une liste de tests qui s’exécuteront en mode Edit, en mode Play, ou les deux, sans les exécuter. Vous pouvez vous connecter à certains rappels d’enregistrement/de désenregistrement au début et à la fin de chaque test, ainsi qu’à tout niveau du cycle de test, autrement dit sur l’ensemble de l'assemblage de tests, sur chaque montage de test particulier et sur tout(e) classe de test et test.
Au début de chaque test, vous obtenez des informations sur l’itinéraire de test sur le point d’être exécuté. Une fois le test terminé, ses résultats s’affichent.
En plus d'exécuter UTF en mode Play dans l’Éditeur Unity, un nouveau point de personnalisation vous permet de l’exécuter sur des appareils cibles. Ceci est invoqué avant la compilation du script Player. Par exemple, vous pouvez modifier les options de compilation du script Player pour changer les paramètres d’exécution de test et spécifier les emplacements de compilation.
Scinder la compilation et l’exécution
Il est utile de scinder les processus de compilation et d’exécution si vous souhaitez exécuter des tests sur un appareil cible qui n’est pas connecté à votre machine locale (par exemple, si celui-ci ou plusieurs appareils se trouvent dans le cloud).
Pour ce faire, vous devez tout d’abord personnaliser le processus de compilation du script Player test lui-même. Voici comment procéder :
- Désactivez l’exécution automatique (AutoRun), de sorte qu’après compilation du script Player, elle ne démarre pas et n’exécute pas les tests.
- Enregistrez le script Player dans un emplacement connu plutôt que dans le dossier temporaire du système (où il serait enregistré par défaut).
Ajoutez ensuite des rapports de résultats personnalisés du côté du script Player (à l’aide de l’interface de rappel) pour recueillir tous les résultats et les enregistrer dans un fichier XML ou sous tout autre format adapté à votre projet.
Consultez les exemples de code suivants pour scinder compilation et exécution. Dans la session Unite (à 6:28), Richard Fine vous guide pas à pas dans le code des deux parties de cette application (la compilation et la création de rapports de résultats).
Scinder la compilation et l’exécution : compilation
Compilation :
Scinder la compilation et l’exécution : enregistrer les résultats lors de l’exécution
Exécution :
Exécution de tests avant la compilation
L’exécution de tests avant la compilation peut s’avérer délicate, car le processus de compilation nécessite l’exécution des tests à partir d’un rappel. Il n’y a donc aucune possibilité de lancer la boucle de mise à jour du moteur. Cependant, l'avantage est que vous pouvez vérifier que les fonctionnalités de base sont opérationnelles avant de consacrer du temps à la compilation (ce qui peut prendre plusieurs minutes pour certains projets).
Vous pouvez implémenter cette application à l’aide de l’interface IPreprocessBuildWithReport, de la même façon que vous le feriez pour tout autre type de prétraitement de compilation. Pour obtenir les résultats, enregistrez un rappel comme d'habitude.
Puisque vous ne pouvez pas passer en mode Play au milieu d’une compilation, vous pouvez utiliser l’API Test Runner pour exécuter des tests spécifiques en mode Edit. Vous pouvez sélectionner ces tests en les filtrant par catégorie, comme une catégorie de test de validation précompilation. Il est possible d’exécuter ces tests de manière synchrone.
À l’issue du test, vérifiez les résultats. En cas de problème, vous pourrez lever une exception BuildFailed, ce qui entraînera l’abandon du processus de compilation.
Cette application peut être divisée en deux parties : le ResultCollector et le préprocesseur, détaillées par Richard lors de sa présentation (à 15:20).
Regarder la démonstration en direct de l’API Test Runner effectuée par Christian et Richard. Visionnez toute la session pour obtenir davantage de conseils en matière d'assurance qualité !