Êtes-vous curieux de savoir comment les tests unitaires fonctionnent dans Unity? Vous ne savez pas ce que sont les tests unitaires en général? Si vous avez répondu positivement à ces questions, ce tutoriel vous sera utile. De là, vous apprendrez ce qui suit sur les tests unitaires:
- Qu'est ce que c'est
- Son avantage
- Avantages et inconvénients
- Fonctionnement dans Unity à l'aide de Test Runner
- Comment écrire et exécuter des tests unitaires qui seront testés
Remarque : ce didacticiel suppose que vous connaissez le langage C # et les bases du développement dans Unity. Si vous débutez avec Unity, consultez d'abord les autres didacticiels sur ce moteur .
Qu'est-ce qu'un test unitaire?
Avant de plonger dans le code, il est important de bien comprendre ce qu'est le test unitaire. Autrement dit, les tests unitaires testent ... les unités.
Le test unitaire (idéalement) est conçu pour tester une unité de code distincte. La composition d'une «unité» peut varier, mais il est important de se rappeler que les tests unitaires doivent tester exactement un «élément» à la fois.
Des tests unitaires doivent être créés pour vérifier qu'un petit morceau logique de code dans un scénario particulier s'exécute exactement comme prévu. Cela peut être difficile à comprendre avant de commencer à écrire vos propres tests unitaires, alors regardons un exemple:
Vous avez écrit une méthode qui permet à l'utilisateur d'entrer un nom. La méthode est écrite de manière à ce que les nombres ne soient pas autorisés dans le nom, et le nom lui-même ne peut contenir que dix caractères ou moins. Votre méthode intercepte la frappe de chaque touche et ajoute le caractère correspondant au champ de
name :
public string name = "" public void UpdateNameWithCharacter(char: character) {
Que se passe-t-il ici:
- Si le caractère n'est pas une lettre, le code pré-quitte la fonction et n'ajoute pas le caractère à la chaîne.
- Si le nom comporte dix caractères ou plus, le code ne permet pas à l'utilisateur d'ajouter un autre caractère.
- Si ces deux vérifications sont réussies, le code ajoute un caractère à la fin du nom.
Cette unité peut être testée, car il s'agit d'un "module" du travail effectué. Les tests unitaires
appliquent la logique des méthodes.
Exemple de test unitaire
Comment écrire des tests unitaires pour la méthode
UpdateNameWithCharacter ?
Avant de commencer à implémenter ces tests unitaires, nous devons examiner attentivement ce que font ces tests et trouver des noms pour eux.
Jetez un œil aux exemples de nom de test unitaire ci-dessous. D'après les noms, il doit être clair qu'ils vérifient:
UpdateNameDoesntAllowCharacterAddingToNameIfNameIsTenOrMoreCharactersInLengthUpdateNameAllowsLettersToBeAddedToNameUpdateNameDoesntAllowNonLettersToBeAddedToNameÀ partir de ces noms de méthodes de test, nous voyons que nous vérifions vraiment si «l'unité» de travail est
UpdateNameWithCharacter par la méthode
UpdateNameWithCharacter . Ces noms de test peuvent sembler trop longs et trop détaillés, mais c'est bon pour nous.
Chaque test unitaire que vous écrivez fait partie d'une suite de tests.
La suite de tests contient tous les tests unitaires liés au groupe logique fonctionnel (par exemple, «tests unitaires de combat»). Si un test du kit échoue, la suite de tests entière échoue.
Lancement du jeu
Ouvrez le
projet Crashteroids Starter (vous pouvez le télécharger à
partir d'ici ), puis ouvrez la scène de
jeu depuis le dossier
Assets / RW / Scenes .
Cliquez sur
Play pour lancer Crashteroids, puis cliquez sur le bouton
Start Game . Déplacez le vaisseau spatial avec les flèches
gauche et
droite du clavier.
Pour tirer un faisceau laser, appuyez sur la
barre d'espace . Si le faisceau frappe l'astéroïde, alors le score augmentera de un. Si un astéroïde entre en collision avec un navire, le navire explose et le jeu se termine (avec la possibilité de recommencer).
Essayez de jouer un peu et assurez-vous qu'après la collision de l'astéroïde avec le navire apparaît l'inscription Game Over.
Premiers pas avec Unity Test Runner
Maintenant que nous savons comment fonctionne le jeu, il est temps d'écrire des tests unitaires pour vérifier que tout fonctionne comme il se doit. Ainsi, si vous (ou quelqu'un d'autre) décide de mettre à jour le jeu, vous serez sûr que la mise à jour ne cassera rien qui ait fonctionné auparavant.
Pour écrire des tests, vous devez d'abord vous renseigner sur le lanceur de tests Unity.
Test Runner vous permet d'exécuter des tests et de vérifier s'ils réussissent. Pour ouvrir le Runner de test Unity, sélectionnez
Fenêtre ▸ Général ▸ Runner de test .
Une fois le Test Runner ouvert dans une nouvelle fenêtre, vous pouvez vous simplifier la vie en cliquant sur la fenêtre du Test Runner et en le
faisant glisser à l'endroit à côté de la fenêtre Scene.
Préparation de NUnit et des dossiers de test
Test Runner est une fonctionnalité de test unitaire fournie par Unity, mais elle utilise le framework
NUnit . Lorsque vous commencez à travailler avec des tests unitaires plus sérieusement, je vous recommande d'étudier le
wiki sur NUnit pour en savoir plus. Tout ce dont vous avez besoin pour la première fois sera abordé dans cet article.
Pour exécuter les tests, nous devons d'abord créer un dossier de test dans lequel les classes de test seront stockées.
Dans la fenêtre
Projet, sélectionnez le dossier
RW . Jetez un œil à la fenêtre
Test Runner et assurez-vous que
PlayMode est sélectionné.
Cliquez sur le bouton intitulé
Créer un dossier d'assemblage de test PlayMode . Vous verrez un nouveau dossier apparaître dans le dossier RW. Nous sommes satisfaits du nom standard
Tests , vous pouvez donc simplement appuyer sur
Entrée .
Vous vous demandez peut-être quels sont ces deux onglets différents dans Test Runner.
L'onglet
PlayMode est utilisé pour les tests effectués en mode Play (lorsque le jeu s'exécute en temps réel). Les tests de l'onglet
EditMode sont exécutés en dehors du mode Lecture, ce qui est pratique pour tester des choses comme les comportements personnalisés dans l'inspecteur.
Dans ce tutoriel, nous couvrirons les tests PlayMode. Mais lorsque vous vous sentez à l'aise, vous pouvez essayer d'expérimenter les tests dans EditMode.
Lorsque vous travaillez avec Test Runner dans ce didacticiel, assurez-vous toujours que l'onglet PlayMode est sélectionné .
Que contient la suite de tests?
Comme nous l'avons appris ci-dessus, un test unitaire est une fonction qui teste le comportement d'un petit morceau de code spécifique. Le test unitaire étant une méthode, pour l'exécuter, il doit être dans le fichier de classe.
Test Runner contourne tous les fichiers de classe de test et effectue des tests unitaires à partir d'eux. Un fichier de classe contenant des tests unitaires est appelé une suite de tests.
Dans la suite de tests, nous subdivisons logiquement nos tests. Nous devons séparer le code de test en ensembles logiques distincts (par exemple, un ensemble de tests pour la physique et un ensemble distinct pour la bataille). Dans ce tutoriel, nous n'avons besoin que d'un seul ensemble de tests, et il est temps d'en créer un.
Préparation d'un ensemble de tests et d'une suite de tests
Sélectionnez le dossier
Tests et dans la fenêtre
Test Runner cliquez sur le bouton
Créer un script de test dans le dossier actuel . Nommez le nouveau fichier
TestSuite .
En plus du nouveau fichier C #, le moteur Unity crée également un autre fichier appelé
Tests.asmdef . Il s'agit du
fichier de définition d'assembly , qui est utilisé pour montrer à Unity où se trouvent les dépendances du fichier de test. Cela est nécessaire car le code d'application fini est contenu séparément du code de test.
Si vous avez une situation où Unity ne peut pas trouver de fichiers de test ou de tests, assurez-vous qu'il existe un fichier de définition d'assembly qui inclut votre suite de tests. L'étape suivante consiste à le configurer.
Pour que le code de test ait accès aux classes de jeu, nous allons créer un assemblage du code de classe et définir le lien dans l'assemblage de tests. Cliquez sur le dossier
Scripts pour le sélectionner. Cliquez avec le bouton droit sur ce dossier et sélectionnez
Créer Definition Définition d'assemblage .
Nommez le fichier
GameAssembly .
Cliquez sur le dossier
Tests , puis sur le fichier de définition de génération de
tests . Dans l'
inspecteur, cliquez sur le bouton
plus sous l'en-tête
Références de définition d'assemblage .
Vous verrez le champ
Référence manquante . Cliquez sur le
point à côté de ce champ pour ouvrir la fenêtre de sélection. Sélectionnez le fichier
GameAssembly .
Vous devriez voir le fichier d'assemblage GameAssembly dans la section des liens. Cliquez sur le bouton
Appliquer pour enregistrer ces modifications.
Si vous ne suivez pas ces étapes, vous ne pourrez pas référencer les fichiers de classe du jeu dans les fichiers de test unitaire. Après avoir traité cela, vous pouvez passer au code.
Nous écrivons le premier test unitaire
Double-cliquez sur le script
TestSuite pour l'ouvrir dans l'éditeur de code. Remplacez tout le code par ceci:
using UnityEngine; using UnityEngine.TestTools; using NUnit.Framework; using System.Collections; public class TestSuite { }
Quels tests devons-nous passer? Honnêtement, même dans un petit jeu comme Crashteroids, vous pouvez écrire pas mal de tests pour vérifier que tout fonctionne comme il se doit. Dans ce didacticiel, nous nous limitons à des domaines clés: la reconnaissance des collisions et les mécanismes de jeu de base.
Remarque : lorsqu'il s'agit d'écrire des tests unitaires d'un produit à un niveau de production, vous devez payer suffisamment de temps pour prendre en compte tous les cas limites qui doivent être testés dans tous les domaines du code.
Comme premier test, il est agréable de vérifier si les astéroïdes descendent vraiment. Il leur sera difficile d'entrer en collision avec le navire s'ils s'en éloignent! Ajoutez la méthode et la variable privée
suivantes au script
TestSuite :
private Game game;
Il n'y a que quelques lignes de code, mais elles font beaucoup de choses. Alors arrêtons-nous et traitons chaque partie:
- Ceci est un attribut . Les attributs définissent des comportements spécifiques du compilateur. Cet attribut indique au compilateur Unity que le code est un test unitaire. Pour cette raison, il apparaîtra dans le Test Runner lors du démarrage des tests.
- Créez une instance de Game. Tout le reste est intégré dans le jeu, donc lorsque nous le créerons, il contiendra tout ce qui doit être testé. Dans un environnement de production, il est fort probable que tous les éléments ne se trouvent pas dans le même préfabriqué. Par conséquent, vous devrez recréer tous les objets nécessaires dans la scène.
- Ici, nous créons un astéroïde afin de pouvoir surveiller s'il bouge. La méthode
SpawnAsteroid renvoie une instance de l'astéroïde créé. Le composant Asteroid a une méthode Move (si vous êtes curieux de savoir comment fonctionne le mouvement, vous pouvez jeter un œil au script Asteroid dans RW / Scripts ). - Le suivi de la position de départ est nécessaire pour s'assurer que l'astéroïde est descendu.
- Tous les tests unitaires Unity sont des coroutines, vous devez donc ajouter un retour progressif. Nous ajoutons également un pas de temps de 0,1 seconde pour simuler le passage du temps pendant lequel l'astéroïde était censé descendre. Si vous n'avez pas besoin de simuler un pas de temps, vous pouvez retourner null.
- Il s'agit de l'étape d' affirmation , dans laquelle nous affirmons que la position de l'astéroïde est inférieure à la position initiale (c'est-à-dire qu'elle a baissé). La compréhension des assertions est une partie importante des tests unitaires, et NUnit propose diverses méthodes d'assertion. La réussite ou l'échec du test est déterminé par cette ligne.
- Bien sûr, personne ne vous réprimandera pour le gâchis qui reste après la fin des tests, mais d'autres tests peuvent échouer à cause de cela. Il est toujours important de nettoyer (supprimer ou réinitialiser) le code après le test unitaire, de sorte que lorsque vous exécutez le prochain test unitaire, il ne reste aucun artefact susceptible d'affecter ce test. Il nous suffit de supprimer simplement l'objet du jeu, car pour chaque test, nous créons une toute nouvelle instance du jeu.
Réussite des tests
Eh bien, vous avez écrit votre premier test unitaire, mais comment savoir si cela fonctionne? Bien sûr, avec Test Runner! Dans la fenêtre Test Runner, développez toutes les lignes avec des flèches. Vous devriez voir le test
AsteroidsMoveDown dans la liste avec des cercles gris:
Un cercle gris indique que le test n'est pas encore terminé. Si le test a été démarré et réussi, une flèche verte s'affiche à côté. Si le test a échoué, un X rouge s'affiche à côté de lui. Exécutez le test en cliquant sur le bouton
RunAll .
Cela créera une scène temporaire et exécutera le test. Une fois terminé, vous devriez voir que le test a réussi.
Vous avez réussi votre premier test unitaire indiquant que les astéroïdes créés se déplacent vers le bas.
Remarque : avant de commencer à écrire vos propres tests unitaires, vous devez comprendre l'implémentation que vous testez. Si vous êtes curieux de savoir comment fonctionne la logique que vous testez, étudiez le code dans le dossier RW / Scripts .
Utilisation de tests d'intégration
Avant d'aller plus loin dans le lapin des tests unitaires, il est temps de dire ce que sont les tests d'intégration et en quoi ils diffèrent des tests unitaires.
Les tests d'intégration sont des tests qui vérifient comment les "modules" du code fonctionnent ensemble. «Module» est un autre terme flou. Une différence importante est que les tests d'intégration doivent tester le fonctionnement du logiciel en production réelle (c'est-à-dire quand un joueur joue vraiment à un jeu).
Disons que vous avez créé un jeu de bataille où un joueur tue des monstres. Vous pouvez créer un test d'intégration pour vous assurer que lorsqu'un joueur tue 100 ennemis, un succès est ouvert («Succès»).
Ce test affectera plusieurs modules de code. Très probablement, il concernera le moteur physique (reconnaissance des collisions), les répartiteurs ennemis (surveillance de la santé de l'ennemi et traitement des dégâts, ainsi que le passage à d'autres événements connexes) et un tracker d'événements qui suit tous les événements déclenchés (par exemple, «le monstre est tué»). Puis, quand il est temps de débloquer la réussite, il peut appeler le gestionnaire de réussite.
Le test d'intégration simulera le joueur tuant 100 monstres et vérifiera si le succès est débloqué. Il est très différent du test unitaire car il teste de gros composants de code qui fonctionnent ensemble.
Dans ce tutoriel, nous n'étudierons pas les tests d'intégration, mais cela devrait montrer la différence entre l'unité de travail (et pourquoi il est testé unitairement) et le module du code (et pourquoi il est testé d'intégration).
Ajout d'un test à une suite de tests
Le prochain test testera la fin du jeu lorsque le vaisseau entre en collision avec un astéroïde. Avec
TestSuite ouvert dans l'
éditeur de code, ajoutez le test ci-dessous sous le premier test unitaire et enregistrez le fichier:
[UnityTest] public IEnumerator GameOverOccursOnAsteroidCollision() { GameObject gameGameObject = MonoBehaviour.Instantiate(Resources.Load<GameObject>("Prefabs/Game")); Game game = gameGameObject.GetComponent<Game>(); GameObject asteroid = game.GetSpawner().SpawnAsteroid();
Nous avons déjà vu la plupart de ce code dans le test précédent, mais il existe quelques différences:
- Nous forçons l'astéroïde et le vaisseau à entrer en collision, donnant clairement à l'astéroïde la même position que le vaisseau. Cela créera une collision de leurs hitbox et conduira à la fin du jeu. Si vous êtes curieux de savoir comment ce code fonctionne, jetez un œil aux fichiers Ship , Game et Asteroid dans le dossier Scripts.
- Un pas de temps est nécessaire pour que l'événement Collision du moteur physique se déclenche, un délai de 0,1 seconde est donc renvoyé.
- Cette déclaration est vraie et vérifie que l'indicateur
gameOver du script Game est vrai. Le drapeau devient vrai pendant le jeu, lorsque le navire est détruit, c'est-à-dire que nous testons pour nous assurer qu'il est réglé sur vrai après la destruction du navire.
Revenez à la fenêtre Test Runner et vous verrez qu'un nouveau test unitaire y est apparu.
Cette fois, nous exécuterons celui-ci au lieu de l'ensemble de la suite de tests. Cliquez sur
GameOverOccursOnAsteroidCollision , puis sur le bouton
Exécuter la sélection .
Et voila, nous avons passé un autre test.
Étapes de réglage et de destruction
Vous avez peut-être remarqué que dans nos deux tests, il y a du code répétitif: où l'objet Game est créé et où un lien vers le script Game est défini:
GameObject gameGameObject = MonoBehaviour.Instantiate(Resources.Load<GameObject>("Prefabs/Game")); game = gameGameObject.GetComponent<Game>();
Vous remarquerez également qu'il y a une répétition dans la destruction de l'objet Game:
Object.Destroy(game.gameObject);
Lors des tests, cela se produit très souvent. Lorsqu'il s'agit d'exécuter des tests unitaires, il y a en fait deux phases: la phase de
configuration et la phase de
démontage .
Tout le code à l'intérieur de la méthode de configuration sera exécuté avant le test unitaire (dans cet ensemble), et tout le code à l'intérieur de la méthode Tear Down sera exécuté après le test unitaire (dans cet ensemble).
Il est temps de simplifier nos vies en déplaçant le code de configuration et de suppression vers des méthodes spéciales. Ouvrez l'éditeur de code et ajoutez le code suivant au début du fichier
TestSuite , juste avant le premier attribut [UnityTest]:
[SetUp] public void Setup() { GameObject gameGameObject = MonoBehaviour.Instantiate(Resources.Load<GameObject>("Prefabs/Game")); game = gameGameObject.GetComponent<Game>(); }
L'attribut
SetUp indique que cette méthode est appelée avant chaque
SetUp test.
Ajoutez ensuite la méthode suivante et enregistrez le fichier:
[TearDown] public void Teardown() { Object.Destroy(game.gameObject); }
L'attribut
TearDown indique que cette méthode est appelée après chaque
TearDown test.
Après avoir préparé le code de configuration et de destruction, supprimez les lignes de code présentes dans ces méthodes et remplacez-les par des appels aux méthodes correspondantes. Après cela, le code ressemblera à ceci:
public class TestSuite { private Game game; [SetUp] public void Setup() { GameObject gameGameObject = MonoBehaviour.Instantiate(Resources.Load<GameObject>("Prefabs/Game")); game = gameGameObject.GetComponent<Game>(); } [TearDown] public void Teardown() { Object.Destroy(game.gameObject); } [UnityTest] public IEnumerator AsteroidsMoveDown() { GameObject asteroid = game.GetSpawner().SpawnAsteroid(); float initialYPos = asteroid.transform.position.y; yield return new WaitForSeconds(0.1f); Assert.Less(asteroid.transform.position.y, initialYPos); } [UnityTest] public IEnumerator GameOverOccursOnAsteroidCollision() { GameObject asteroid = game.GetSpawner().SpawnAsteroid(); asteroid.transform.position = game.GetShip().transform.position; yield return new WaitForSeconds(0.1f); Assert.True(game.isGameOver); } }
Test du Game Over et du tir laser
Après avoir préparé les méthodes de réglage et de destruction qui simplifient nos vies, nous pouvons commencer à ajouter de nouveaux tests dans lesquels ils sont utilisés. Le test suivant consiste à vérifier que lorsqu'un joueur clique sur
New Game , la valeur de
gameOver bool n'est pas vraie. Ajoutez un tel test à la fin du fichier et enregistrez-le:
[UnityTest] public IEnumerator NewGameRestartsGame() {
Cela devrait déjà vous sembler familier, mais il convient de mentionner ce qui suit:
- Ce morceau de code prépare ce test pour que le drapeau booléen
gameOver soit vrai. Lors de l'appel de la méthode NewGame , il doit à nouveau définir l'indicateur sur false . - Ici, nous soutenons que bool
isGameOver est false , ce qui devrait être vrai lors de l'appel d'un nouveau jeu.
Revenez à Test Runner et vous devriez voir qu'il y a un nouveau test
NewGameRestartsGame . Exécutez ce test, comme nous l'avons fait auparavant, et vous verrez qu'il s'exécute avec succès:
Déclaration du faisceau laser
Le prochain test consiste à ajouter le test selon lequel le faisceau laser tiré par le navire vole (semblable au premier test unitaire que nous avons écrit). Ouvrez le fichier
TestSuite dans l'éditeur. Ajoutez la méthode suivante et enregistrez le fichier:
[UnityTest] public IEnumerator LaserMovesUp() {
Voici ce que fait ce code:
- Obtient un lien vers le faisceau laser généré émis par le navire.
- La position de départ est enregistrée afin que nous puissions vérifier qu'elle monte.
- Cette déclaration est cohérente avec la déclaration du test unitaire
AsteroidsMoveDown , seulement maintenant nous affirmons que la valeur est supérieure (c'est-à-dire que le laser monte).
Enregistrez le fichier et revenez à Test Runner. Exécutez le test LaserMovesUp et observez comment il passe:Maintenant, vous devriez déjà commencer à comprendre comment tout fonctionne, il est donc temps d'ajouter les deux derniers tests et de terminer le didacticiel.Vérifier que le laser détruit les astéroïdes
Ensuite, nous nous assurerons que lorsqu'il est touché, le laser détruit l'astéroïde. Ouvrez l'éditeur et ajoutez le test suivant à la fin de TestSuite , puis enregistrez le fichier: [UnityTest] public IEnumerator LaserDestroysAsteroid() {
Voici comment cela fonctionne:- Nous créons un astéroïde et un faisceau laser, et leur attribuons la même position pour déclencher une collision.
- Il s'agit d'un test spécial avec une distinction importante. Vous voyez que nous utilisons explicitement UnityEngine.Assertions pour ce test ? En effet, Unity a une classe Null spéciale qui est différente de la classe Null «régulière». Une instruction d'infrastructure NUnit
Assert.IsNull() ne fonctionnera pas dans les contrôles Unity pour null. Lors de la vérification de null dans Unity, vous devez utiliser explicitement UnityEngine.Assertions.Assert, et non Assert à partir de NUnit.
Revenez à Test Runner et exécutez un nouveau test. Vous verrez une icône verte nous plaire.Tester ou ne pas tester - telle est la question
La décision de s'en tenir aux tests unitaires n'est pas une décision facile et ne doit pas être prise à la légère. Cependant, les avantages des tests valent la peine. Il y a même une méthodologie de développement, appelé le développement piloté par les tests (Test Driven Development, TDD).En travaillant dans le cadre de TDD, vous écrivez des tests avant d'écrire la logique d'application elle-même. Tout d'abord, vous créez des tests, assurez-vous que le programme ne les réussit pas, puis écrivez uniquement du code conçu pour passer les tests. Cela peut être une approche très différente du codage, mais cela garantit que vous écrivez le code d'une manière adaptée aux tests.Gardez cela à l'esprit lorsque vous commencez à travailler sur votre prochain projet. Mais pour l'instant, il est temps d'écrire vos propres tests unitaires, pour lesquels vous avez besoin d'un jeu que nous vous avons fourni.: — , . , . «» , , . , . , . , , .
Les tests peuvent être un gros investissement, alors considérez les avantages et les inconvénients de l'ajout de tests unitaires à votre projet:Avantages des tests unitaires
Les tests unitaires présentent de nombreux avantages importants, notamment:- Cela donne confiance que la méthode se comporte comme prévu.
- Sert de documentation pour les nouvelles personnes étudiant la base de code (les tests unitaires sont parfaits pour l'enseignement).
- Vous fait écrire du code d'une manière testable.
- Permet d'isoler et de corriger les erreurs plus rapidement.
- Il ne permet pas aux futures mises à jour d'ajouter de nouveaux bogues à l'ancien code de travail (ils sont appelés erreurs de régression).
Inconvénients des tests unitaires
Cependant, vous pouvez ne pas avoir le temps ni le budget pour les tests unitaires. Voici ses inconvénients à considérer:- L'écriture de tests peut prendre plus de temps que le code lui-même.
- .
- .
- , .
- , -.
- ( ), .
- - .
- UI .
- .
- .
,
Il est temps d'écrire le dernier test. Ouvrez l'éditeur de code, ajoutez le code ci-dessous à la fin du fichier TestSuite et enregistrez-le: [UnityTest] public IEnumerator DestroyedAsteroidRaisesScore() {
Il s'agit d'un test important, qui vérifie que lorsqu'un joueur détruit un astéroïde, le score augmente. Voici en quoi il consiste:- Nous créons un astéroïde et un faisceau laser, et les mettons dans une position. Pour cette raison, une collision survient qui déclenche une augmentation du score.
- La déclaration selon laquelle game.score est désormais de 1 (et non de 0, comme c'était le cas au début).
Enregistrez le code et revenez à Test Runner pour exécuter ce dernier test et voir s'il exécute le jeu:Génial! Tous les tests ont réussi.Où aller ensuite?
Dans l'article, nous avons examiné une grande quantité d'informations. Si vous souhaitez comparer votre travail avec le projet final, regardez-le dans les archives , dont un lien est également indiqué au début de l'article.Dans ce didacticiel, vous avez appris ce que sont les tests unitaires et comment les écrire dans Unity. En outre, vous avez écrit six tests unitaires qui ont réussi le code et vous êtes familiarisé avec certains des avantages et des inconvénients des tests unitaires.Vous vous sentez confiant? Ensuite, vous pouvez écrire de nombreux autres tests. Examinez les fichiers de classe du jeu et essayez d'écrire des tests unitaires pour d'autres parties du code. Pensez à ajouter des tests pour les scénarios suivants:- Chaque type d'astéroïde lorsque vous touchez le vaisseau mène à la fin de la partie.
- Commencer une nouvelle partie réinitialise le score.
- Le mouvement à gauche et à droite du navire fonctionne correctement.
Si vous souhaitez approfondir vos connaissances sur les tests unitaires, il vaut la peine d'explorer la mise en œuvre de dépendances et de cadres pour travailler avec des objets fictifs . Cela peut grandement simplifier la configuration du test.Lisez également la documentation NUnit pour en savoir plus sur le cadre NUnit.Et n'hésitez pas à partager vos réflexions et vos questions sur les forums.Test réussi!