How to Unit Test? Where is the Unity.Entities.Tests namespace?

Hello!

So I recently moved from Unity 5 to Unity 2018 so I can work with the ECS. I'm running into some problems getting ECS Unit Tests running. I was attempting to follow this video.

• When I put my test script in an Editor folder, I am not able to find the Unity.Entities.Tests namespace, or the ECSTestsFixture base class.

• When I put my test script in a Tests folder, I can't find the Unity.Entities namespace. I don't think "Tests" was a special folder in Unity 5.

• In the video, it looks like references to these namespaces were added to a "Assembly Definition" which also seems new to Unity. In the video, they are able to add packages like Unity.Mathematics or Unity.Entities.Editor.Tests. I don't see a list of any of these packages. Where can I find them?

Thanks for any help!

 

This is the point in the video where I can no longer follow.

 

You can manually edit the asmdef file to include "Unity.Entities.Tests". For some reason that inspector window broke again and doesn't display assembly def references for the unity packages, although on several of the beta builds it was working for a while.

 

The Tests.asmdef file looked like JSON, so I added "Unity.Entities", "Unity.Entities.Tests", and ""Unity.Entities.Editor.Tests".

Code (JavaScript):

1. {
2.     "name": "Tests",
3.     "references": [
4.         "Unity.Entities",
5.         "Unity.Entities.Tests",
6.         "Unity.Entities.Editor.Tests"
7.     ],
8.     "optionalUnityReferences": [
9.         "TestAssemblies"
10.     ],
11.     "includePlatforms": [
12.         "Editor"
13.     ],
14.     "excludePlatforms": [],
15.     "allowUnsafeCode": false
16. }

This allowed these references to appear in the Unity Inspector.


However, the namespace is still missing in code.


Both the .asmdef file and the AnnounceSystemTest.cs file are in a "Tests" folder. I'm on Unity 2018.1.7f1 with the Entities 0.0.12-preview.8 package.

Why is the namespace still not found? Are there any example projects with ECS tests included so I can see a working example?

 

If feasible, try deleting any *.rsp, *.csproj, and *.sln files generated by Unity and then reopening it.

If that doesn't work, you may need to not only clean those out but also do this additional step:

Exit Unity. Look for the project directory where "Assets" folder lives. Delete Temp directory (if it still exists) delete obj directory (if it exists). Delete Library folder. Reopening Unity should trigger a clean packages pull and recompile of your project.

 

Sorry to hear you're having trouble with this. Let us know if you get it working!

 

I have same issue as Garth-Smith. Unity.Entities.Tests.dll is not in Library/ScriptAssemblies. I am using 2018.2.2f1. Tried reimport all. Suggestions?

 

I haven't run tests.
But i searched quickly my assets folder and found two.

Unity.Jobs.Tests.dll
and
Unity.Collections.Tests.dll

which are located in
Project folder -> \Library\ScriptAssemblies\

But don't know, if this what you are looking for.

 

Thank you. I tried both and unfortunately neither had ECSTestsFixture defined. So I ended up installing "preview 2" of entities package which included Unity.Entities.Tests and copied ECSTestsFixture and its dependencies on EcsTestData varieties into my test code base for now. Also had to change World.Active to be static. Then reinstalled "preview 8" which is currently the latest version. Example from charlesmat ran and passed so it seems to work. I assume Unity will add Unity.Entities.Tests back in a later version.

 

I have the same problem, did they remove the ECS testing assembly in preview 8? I would love to try ECS test tools, being an essential part in data oriented design.

 

I installed Unity 2018.2.5f1 which allowed me to try importing Entities 0.0.12-preview.2 and Entities 0.0.12-preview.11.

However, I still don't see a list of any references to add to my .asmdef file. I still cannot find the Unity.Entities.Tests namespace anywhere.

Has anyone been able to get testing working with Entities on a fresh install of Unity?

 

You have to:

1. Click on your asmdef file to show it in the inspector (for example Main.Tests.asmdef)
2. In inspector/References click a "+" sign to add a new reference field
3. In Project explorer locate asmdef file of your reference (for example packages/unity.entities.tests/unity.entities.tests.asmdef)
4. Drag and drop this file to your new references field
5. Click apply to confirm changes

EDIT: I have noticed you referenced the tutorial from Infallible Code in your original post. While I like Charles Amat's tutorials, this one could be done better. Referencing Unity's test base class is unnecessary shortcut, he should explain how to create your own test base class. It is pretty easy and much better option then deriving from ECSTEstsFixture, which could be changed anytime in the future and break your code.

 

I have this problem too in 2018.2.13f and in 2018.3.0b6.

I tried double click in inspector and copy whole unity.entities.tests folder to my Assets/Tests folder
But it does not work too.

I copied ECSTestsFixture.cs and TestComponents.cs to my Tests folder, also I have fix includes.
And it seems that it works.

 

Using Unity 2019.1.0a10, Unity.Entities 0.0.12-preview.21 issue still persists.

This suggestions works!

Thanks

 

Something is definitiely broken with the assembly definitions for Unity.Entities.Tests.
When I include only Unity.Entities in my asmdef, I can reference the namespace "Unity.Entities" in a script.
When I add Unity.Entities AND Unity.Entities.Tests, I cannot even reference the namespace "Unity.Entities" at all.

 

Works fine for me, but I have to set it up a specific way.

The main thing is, manifest.json must include the "com.unity.entities" as a testable, this is what mine looks like

Code (csharp):

1.   "testables": [
2.     "com.unity.collections",
3.     "com.unity.entities",
4.     "com.unity.jobs",
5.     "com.unity.test-framework.performance"
6.   ],
7.  

Then your test asmdef should reference both the tests and the base package, mine looks like this (with a few extra libraries in there)

Code (CSharp):

1.  
2. {
3.     "name": "Shattered.Testing",
4.     "references": [
5.         "Shattered",
6.         "Unity.Mathematics",
7.         "Common",
8.         "Zenject-TestFramework",
9.         "Unity.Entities",
10.         "Unity.Entities.Hybrid",
11.         "Unity.Collections",
12.         "Unity.Entities.Tests",
13.         "Unity.Transforms",
14.         "BovineLabs.Entities"
15.     ],
16.     "optionalUnityReferences": [
17.         "TestAssemblies"
18.     ],
19.     "includePlatforms": [
20.         "Editor"
21.     ],
22.     "excludePlatforms": [],
23.     "allowUnsafeCode": false,
24.     "overrideReferences": false,
25.     "precompiledReferences": [],
26.     "autoReferenced": true,
27.     "defineConstraints": []
28. }
29.  

 

omg, I have been wondering for months if it is a bug and I have to copy the test fixture class to my own asmdef.. so this "testables" is only editable via text editor?

 

I believe so and adding it will solve all your issues

 

Adding those testables on Unity 2019.1.0a14 get me:

Code (CSharp):

1. Library\PackageCache\com.unity.entities@0.0.12-preview.23\Unity.Entities.PerformanceTests\EntitySerializationPerformanceTests.cs(136,10): error CS0246: The type or namespace name 'PerformanceTest' could not be found (are you missing a using directive or an assembly reference?)

Here are my manifest.json

Code (CSharp):

1. {
2.   "dependencies": {
3.     "com.unity.burst": "0.2.4-preview.41",
4.     "com.unity.collections": "0.0.9-preview.11",
5.     "com.unity.entities": "0.0.12-preview.23",
6.     "com.unity.jobs": "0.0.7-preview.6",
7.     "com.unity.mathematics": "0.0.12-preview.19",
8.     "com.unity.package-manager-ui": "2.1.1",
9.     "com.unity.rendering.hybrid": "0.0.1-preview.3",
10.     "com.unity.modules.ai": "1.0.0",
11.     "com.unity.modules.animation": "1.0.0",
12.     "com.unity.modules.assetbundle": "1.0.0",
13.     "com.unity.modules.audio": "1.0.0",
14.     "com.unity.modules.cloth": "1.0.0",
15.     "com.unity.modules.director": "1.0.0",
16.     "com.unity.modules.imageconversion": "1.0.0",
17.     "com.unity.modules.imgui": "1.0.0",
18.     "com.unity.modules.jsonserialize": "1.0.0",
19.     "com.unity.modules.particlesystem": "1.0.0",
20.     "com.unity.modules.physics": "1.0.0",
21.     "com.unity.modules.physics2d": "1.0.0",
22.     "com.unity.modules.screencapture": "1.0.0",
23.     "com.unity.modules.terrain": "1.0.0",
24.     "com.unity.modules.terrainphysics": "1.0.0",
25.     "com.unity.modules.tilemap": "1.0.0",
26.     "com.unity.modules.ui": "1.0.0",
27.     "com.unity.modules.uielements": "1.0.0",
28.     "com.unity.modules.umbra": "1.0.0",
29.     "com.unity.modules.unityanalytics": "1.0.0",
30.     "com.unity.modules.unitywebrequest": "1.0.0",
31.     "com.unity.modules.unitywebrequestassetbundle": "1.0.0",
32.     "com.unity.modules.unitywebrequestaudio": "1.0.0",
33.     "com.unity.modules.unitywebrequesttexture": "1.0.0",
34.     "com.unity.modules.unitywebrequestwww": "1.0.0",
35.     "com.unity.modules.vehicles": "1.0.0",
36.     "com.unity.modules.video": "1.0.0",
37.     "com.unity.modules.vr": "1.0.0",
38.     "com.unity.modules.wind": "1.0.0",
39.     "com.unity.modules.xr": "1.0.0"
40.   },
41.   "testables" : [
42.     "com.unity.collections",
43.     "com.unity.entities",
44.     "com.unity.jobs"
45.   ]
46. }

and my Tests.asmdef

Code (CSharp):

1. {
2.     "name": "Tests",
3.     "references": [
4.         "Unity.Entities.Tests",
5.         "Unity.Entities"
6.     ],
7.     "optionalUnityReferences": [
8.         "TestAssemblies"
9.     ],
10.     "includePlatforms": [
11.         "Editor"
12.     ],
13.     "excludePlatforms": [],
14.     "allowUnsafeCode": false,
15.     "overrideReferences": false,
16.     "precompiledReferences": [],
17.     "autoReferenced": true,
18.     "defineConstraints": [],
19.     "versionDefines": []
20. }

 

Nevermind, just found out that adding com.unity.entities.performancetests as a testable fixes the issue.

 

This was a helpful post. Seems way too tricky to get tests working.
Another note, is there anyway now to get rid of these tests I don't want:


Edit, nevermind. I am just not including testables any more and writing my own ECSTestFixture as per @Fido789 s suggestion

 

I was hoping to write a couple unit tests of a particularly advanced system and I'm running into this issue with Unity.Entities.Test.asmdef being busted. I edited Packages/manifest.json to include "testables" as suggested above, but that doesn't seem to prevent these errors:

Code (CSharp):

1. The type or namespace name 'Tests' does not exist in the namespace 'Unity.Entities' (are you missing an assembly reference?)

and

Code (CSharp):

1. The type or namespace name 'ECSTestsFixture' could not be found (are you missing a using directive or an assembly reference?)

This is in 2019.1.1 with 0.12-preview-30 of Unity.Entities. Is anyone successfully unit testing in this context?

 

The behaviour with cross-assembly test is very buggy, I suggest just make your test self contained for now. (That is just copy ECSTestsFixture as your own subclass)

But if you really want to link I think you need both

Code (CSharp):

1.   "testables": [
2.     "com.unity.entities",
3.     "com.unity.test-framework.performance"
4.   ]

And when I said buggy, sometimes modifying manifest.json will not take effect until you "touch" the test script to refresh the test assemblies (add remove some characters and save). Sometimes you must restart Unity. Sometimes even restarting Unity won't refresh the result. Sometimes after restarting Unity it requires touching the test assembly one more time. Sometimes removing just "com.unity.test-framework.performance" make things still work perfectly, and sometimes throwing different errors.

And lastly the reason for that the test shouldn't be linked is because "testables" will add tests from the other packages to be listed on your game. May not be a big issue but the design is for that only your game's test are in the Test Runner tab. By adding "testables" you get all these in your project :



What problem could it cause? The "Run All" button now doing too much that it should, and also in Play Mode test "Run all in player" button couldn't exclude tests unless you go add [Ignore] on the test code, which you have no access to in this case. It make this button less useful as it wastes time testing packages rather than your game.

 

Thanks for all the details! I just pulled in ECSTestsFixture and TestComponents directly into my tests assembly directory and I'm able to run my ECS tests successfully (when I saw the TestComponents dependency after pulling in just ECSTestsFixture I thought it would be a long chain, but just those two files suffices).

 

I'm having the same issue. Also Fido mentioned that is not a good idea to inherit from ECSTestsFixture. So what the workaround to test ecs?

 

> I just pulled in ECSTestsFixture and TestComponents directly into my tests assembly directory and I'm able to run my ECS tests successfully.

I recommend just copying those two files into your testing directory. I also changed the namespace to match my tests, but I don't think you necessarily need to do that.

 

Even on Version 2019.2.11f1 with entities package 0.1.1 of com.unity.entities, this problem still persists. I attempted to copy ECSTestsFixture and TestComponents to my test folder (where my tests.asmdef sits), but now I get a lovely complaint from ECSTestsFixture.cs:

Assets/Code/Tests/ECSTestsFixture.cs(168,28): error CS1729: 'EntityQueryBuilder' does not contain a constructor that takes 1 arguments

Has anybody had and/or solved the same error?

 

I found adding the packages under testable in the manifest.json, as @5argon provided in his most recent post on this thread

solves the odd, cyclic, reference error

as @diesoftgames originally mentioned, instead of the ECSTestsFixture and TestComponents copying route.

It is enough of a solution for me. The Edit Mode tests are now flooded with >2000 tests from those packages, but I'm currently only implementing Play Mode tests, so I don't have to deal with the bloated testing times.

I hope Unity will resolve this entire issue soon.

 

Just delete that line of code on your copy, you don't really need it for testing.

 

I think we don't really have to reference the official base test assembly for simplicity. If your systems are all well designed this kind of rough base class is servicable enough for all tests. I have been using this for quite sometimes now. Basically it just pours all systems out to the world like real play, each system then will be tested if their query are robust enough or not. Then base your test on calling Update on the `w` world then check things. Make a rule to not ever call .Update on individual system.

Code (CSharp):

1.  
2. public abstract class ECSTestBase
3. {
4.     protected World w { get; private set; }
5.     protected EntityManager em { get; private set; }
6.     protected EntityManagerUtility emu { get; private set; }
7.  
8.     [SetUp]
9.     public void SetUpBase()
10.     {
11.         w = new World("Test World");
12.         em = w.EntityManager;
13.         emq = new EntityManagerUtility(w);
14.         var allSystems =
15.             DefaultWorldInitialization.GetAllSystems(WorldSystemFilterFlags.Default, requireExecuteAlways: false);
16.         allSystems.Add(typeof(ConstantDeltaTimeSystem)); //this has disable auto creation on it.
17.         DefaultWorldInitialization.AddSystemsToRootLevelSystemGroups(w, allSystems);
18.     }
19.  
20.     /// <summary>
21.     /// Call to make the next world update go in a specific time.
22.     /// </summary>
23.     protected void ForceDeltaTime(float deltaTime)
24.     {
25.         w.GetExistingSystem<ConstantDeltaTimeSystem>().ForceDeltaTime(deltaTime);
26.     }
27.  
28.     [TearDown]
29.     public void TearDownBase()
30.     {
31.         w.Dispose();
32.     }
33. }
34.  

Combined with a practice of developing your systems in a separated UPM package in its own project then later link to your main game, the pour all systems from all assemblies is not so bad anymore since there are only those you made and a few from official package. Plus if you do that you have the fastest lane to bug fixes, since you don't want to perform bug report on your main game with GB of assets and you don't have time to make a repro project either. On this separated UPM package it should be less than 1MB of pure ECS code. You can just point out that this test is red because of Unity's bug, then they will be much more happy to fix it to green rather than having to go through your GBs of game assets.

 

Has anyone had any experience developing this way? How did it work out?

 

This is how I develop, everything is grouped into its own package, though only half of them have their own projects. Works great

 

How do you deal with communicating between projects? Do you just set it up so all the code in your sub projects have no dependencies on code in the main project?

 

Exactly.

Only my main project needs to know about every other project. I don't want my libraries all coupled together in a big spaghetti mess and this enforces that.

I've re-used many of these packages in half a dozen different projects. Saves me so much time having no game specific logic in them.

 

Even for packages that doesn't make sense in your other games, if you test drive it in-project first with ASMDEF which enforce no circular dependencies, then you are ready to take them out to empty project.

By doing this it significantly force me to rethink the code but in the end the code looks better. I have something called "Core" package when I can't figure out how to separate. Every sub-packages has reference to the Core.

Particularly something like scene transition code which wants to know every scene to facilitate transition, but each scene which is now its own ASMDEF/UPM wants to be a "leaf" package to develop in isolation. If scene transition code reference scene packages it creates circular dependency. I fix this by having a small fragment of each scene package in the Core, then the core scene transition perform its job by reading/writing data limited to those fragments. Each leaf scene package that could reference the Core can now read it's own fragment area that the transition manager setup.

e.g. at title scene, the TitleLogic code in the Title package will read Core.SceneTransition.TitleFragment.SkipIntro and know that it should skip intro. Having "Title"Fragment in the "Core" package violates the definition of "Core", but this solves difficulty in trying unwinding circular dependencies. Keep the fragment part minimal otherwise your Core will started turning into "Everything" package.