Comment mettre en place des tests unitaires dans Unity et corriger l'erreur de référence d'assemblage manquante ?

Question

J'ai créé la structure suivante :

 Assets
 Scenes
 Scripts
    MyExample.cs
 Tests
    MyExampleTest.cs
    Tests.asmdef

Maintenant, lorsque je clique sur Run All, dans la fenêtre Test Runner, dans Unity, j'ai l'erreur suivante :

The type or namespace name `MyExample' could not be found. Are you missing an assembly reference?

Dans Visual Studio, j'ai deux projets :

• Assembly-CSharp (contenant src)

• Tests (contenant des tests)

J'ai ajouté Assembly-CSharp comme référence dans le second projet. Visual Studio est capable de construire la solution sans aucune erreur.

Quelqu'un sait-il comment configurer correctement une régression UnitTest pour un projet Unity ?

C'est Tests.asmdef

{
    "name": "Tests",
    "optionalUnityReferences": [
        "TestAssemblies"
    ]
}

MonExempleTest.cs

using UnityEngine;
using UnityEngine.TestTools;
using NUnit.Framework;
using System.Collections;
using abc;

public class MyExampleTest{

    [Test]
    public void NewTestScriptSimplePasses() {
        // Use the Assert class to test conditions.
    }

    [UnityTest]
    public IEnumerator NewTestScriptWithEnumeratorPasses() {
        abc.Example m;
        Assert.That(false);
        yield return null;
    }
}

MonExemple.cs

namespace abc
{
    public class Example
    {

    }
}

Answer 1

Essayez d'utiliser l'interface utilisateur intégrée de Test Runner pour configurer votre dossier d'assemblage de test et votre premier script de test.

Utilisez Window -> Test Runner -> EditMode -> "Create Test Assembly Folder" et une fois que vous avez accédé au nouveau dossier d'assemblage de test, utilisez le bouton Create Test Script in current folder bouton.

En particulier, votre Tests.asmdef Il manque une inclusion "Editor" par rapport à la configuration par défaut (dans Unity 2018.1).

{
    "name": "Tests",
    "optionalUnityReferences": [
        "TestAssemblies"
    ],
    "includePlatforms": [
        "Editor"
    ]
}

Vous ne devez rien faire manuellement dans le projet Visual Studio pour mettre en place vos tests.

Notez que lorsque mon fichier d'assemblage est réglé sur "Any Platform" comme suit (comme dans votre question) :

{
    "name": "Tests",
    "optionalUnityReferences": [
        "TestAssemblies"
    ]
}

Mes tests ne s'affichent pas dans la fenêtre de Test Runner.

Lorsque mon fichier d'assemblage est explicitement défini pour inclure uniquement la plate-forme "Editor" (comme dans mon exemple précédent), mes tests s'affichent correctement dans la fenêtre de Test Runner.

(Ce comportement me semble un peu contre-intuitif).

---

Vous devez également mettre en place une définition d'assemblage pour vos scripts. Sous votre Scripts dans le dossier, créer un fichier de définition d'assemblage MyScriptAssembly.asmdef (en utilisant le menu Unité Assets -> Create -> Assembly Definition ou manuellement) :

{
    "name": "MyScriptAssembly"
}

Ensuite, assurez-vous que votre Tests.asmdef faire référence à votre Assemblée script :

{
    "name": "Tests",
    "references": [
        "MyScriptAssembly"
    ],
    "optionalUnityReferences": [
        "TestAssemblies"
    ],
    "includePlatforms": [
        "Editor"
    ],
    "excludePlatforms": [],
    "allowUnsafeCode": false
}

Vous pouvez également le configurer dans la fenêtre de l'inspecteur de l'éditeur Unity. Voir "Références" dans l'inspecteur lors de la sélection d'un fichier .asmdef :

(Pour plus de détails, voir La documentation d'Unity sur les fichiers de définition d'assemblage )

Answer 2

J'ai enfin trouvé la bonne solution à ce problème. Et tout se fait par l'intermédiaire de l'éditeur.

Notre objectif est donc de faire en sorte que l'assemblage de test fasse référence à l'assemblage du code réel. Pour ce faire, vous devez définir les deux assemblées, puis établir la référence dans l'unité.

1. Créez vos tests comme d'habitude à partir d'Unity. Avec la génération de l'assemblage.
2. Allez dans votre dossier scripts (généralement Assets/scripts) et cliquez droit -> Créer une définition d'assemblage cela créera un fichier d'assemblage là aussi.
3. Accédez à l'information sur l'assemblage de vos tests dans l'unité y ajouter une référence à votre assemblage réel et assurez-vous également qu'il n'est marqué que pour la Rédacteur en chef plate-forme.

Tu es prêt. Vos tests devraient être visibles et exécutables dans Unity et ils peuvent référencer n'importe quel autre script.

---

Gardez à l'esprit que vous pouvez supprimer sans risque TOUS les fichiers .csproj et .sln du dossier racine et qu'Unity les recréera (ils ne doivent pas non plus être sous contrôle de source).

Donc votre test pour des changements comme celui-ci devrait toujours être de

1. Supprimez tout fichier relatif à Visual Studio dans le dossier.
2. Sélectionnez Actifs -> Ouvrir un projet C# . Laissez-le faire son travail.
3. Si tout compile et fonctionne et que vos tests le font aussi, vous avez bien mis les choses en place.

---

Bonus : Nous avons également un couple de projets de débogage dans notre projet qui sont situés dans Assets/DebugScenes/DebugScripts . En créant une assemblée séparée pour eux et en la faisant référencer l'assemblée réelle scripts (si nécessaire) et en la marquant en tant que Rédacteur en chef nous nous assurons que ces scripts ne sont jamais inclus dans notre construction sans aucune étape supplémentaire pendant la construction.

---

Lecture supplémentaire. Vous pensez peut-être que vous ne voulez pas créer une assembly pour TOUS vos scripts puisque vous ne voulez en tester que certains. Et c'est vrai que vous pouvez créer une assembly pour un sous-dossier mais cela vous causera des problèmes car vous devrez alors créer une référence d'une vraie assembly scripts à une autre. Donc assurez-vous que tout est bien rangé et a un sens...

---

Answer 3

Lite, "zéro assemblages", configuration alternative :

Assets
├── Scenes
├── Scripts
│   └── MyGameScript.cs
├── Editor
│   └── MyGameScriptTests.cs

Tous les scripts à l'intérieur. Editor peut faire référence à NUnit.Framework et ces tests apparaîtront dans Test Runner fenêtre.

Son principal avantage est sa simplicité. Je suis sûr qu'il y a des inconvénients quelque part, mais pour les projets de tous les jours, c'est une bénédiction ; aucun souci pour le configurer, il fonctionne tout simplement.