I need some newbie help here. I have created a bunch of namespaces with classes and whatnot in them, and stuck them under Assets/_MyProjectName/Scripts. The unit test for these ended up in Assets/Editor/Tests. The unit tests don’t show up in the test runner, and I’m guessing the reason for that is that Unity is complaining about my unit test files not finding my namespaces with the good ol’
The type or namespace name `yadayada’ could not be found. Are you missing a using directive or an assembly reference
I was under the impression that everything under the Assets folder (with the exception of Editor folders) was automatically included in the build, so why can’t my tests find my namespaces?
Same issue here, I get the namespace issue in 2018 but not 2017. I’m noticing that If i add a script with the namespace issue into the same folder as the test’s assembly file, it works. So, I think in 2018 things needs to be managed with regard to the Assemblies. More info here:
and here’s how to work with them:
Seems like all that really needs to be done is …
add the scripts with the namespaces to the folder w/ the .asmdef file the Tester generated, it will pick up the scripts.
go to the folder w/ the scripts you want to reference, and right click, create Assembly Definition. From there, go back to the Assembly reference generated by the Tester, and look at it in the inspector. Find the ‘References’ property, click + to add, and find the Assembly you just created in that other folder. After it’s in the list, scroll down in the inspector to find ‘Save’, click save, let it recompile, and from there, the ‘missing’ references should go away, as they are now accounted for. Here’s some more information:
How to stop having to go through hundreds of inter dependencies across a large project? I’ve got many asset store scripts that I’m referencing. Unless I’m missing something, this is not a solution.
As far as I am aware your unit tests should avoid referencing many external dependencies anyway. Maybe try just testing the behavior of each script separately focusing on the behaviors that in the script. This may take a bit of abstraction but it means your unit tests will still work even if you bring those scripts into another project without all the external dependencies.
You don’t understand. The “solution” above is to manage the assemblies for your code and then reference that managed assembly in your test assembly. However, this in turn generates the same problem for your code as your test assembly had - it can no longer reference non-managed code. So if you have 100 assets, you now need to go through each of them and create a reference to their assemblies (which you may need to make yourself) in the managed assembly for your code.
You can avoid this completly by providing a clean encapsulated architecture. The Ports & Adapters/Hexagonal/Clean Architectures all provide patterns to decouple frameworks completly from application code and then all you need is a single reference to your Adapter.dll which has references to all 3rd party frameworks.
However,… as it is unlikely the above will actually help you or is what you are seeking for, here is a simple solution:
Just move all 3rd party code to a folder /Plugins, create one asmdef Plugins.asmdef in it. Delete all other asmdef files beneath it which are not for /Editor folders. Now you have a single Plugins.asmdef to reference and the /Editor asmdef reference the Plugins.asmdef.
You can go even one step further and add a /Plugins/Editor folder with one Plugins.Editor.asmdef which references Plugins.asmdef and repeat the same for all /Editor folders beneath.
This is something which can be easily automated with an editor script.
Also, the real problem here is not the asmdef but the current IDE support for asmdef files. The Rider team for example is considering to make their reference system asmdef-aware in which case you won’t have to touch the asmdef and simply can add the reference to the assembly and rider will update the asmdef accordingly, s.t. Unitys csproj generation system will not overwrite the change. Just check the amount of references your IDE lists for each of your assemblies (be it with asmdef or without). Having many references is not a problem, a lot of C# code is split among many *.dll and for users of packaging systems like nuget or others the workflow is pretty common.
@haskins the difference between 2017 and 2018 is that Unity itself with it’s packages is moving forward to asmdef. That is why you experience the difference.
@sblandinuk The only reason to not reference many other asmdef is to avoid a) cycles or b) reduce recompilation because of changes in dependencies. Cycles should be no problem in Test as nothing should reference a Test.asmdef in the first place. Recompilation time only matters if you have a problem with the current recompilation time. It is absolutely fine to have one Test.asmdef which references ALL of your other asmdef. Packaging (splitting your code into .asmdef/assemblies/dll) is an implementation detail and should be chosen depending on your specific needs. What you should worry more about is which class sees which class - the actual dependency. Think of asmdef only defining hard boundaries on the possible visibility, it is not the actual dependency. You can reference assemblies you do not even use or need.
Do not get me wrong, there is a lot of stuff I really hate when having to work with asmdef files, but the problems here are solveable.
Good point about bringing 3rd party assets into a separate folder and creating fewer assembly definition files.
Still seems like it could be a lot of work if you’ve got a lot of dependencies. Rolling your own script may be a good idea for those that find themselves in this situation, as you suggest, though it leaves me a bit underwhelmed to think I’d even have to.
I’m probably grossly underestimating the complexity of the situation here, but because test assembly files aren’t shipped in the build, couldn’t this whole issue be avoided if unity had set things up such that test assemblies automatically reference the default assemblies and are built last? From what I understand, the reason you can’t reference the default assemblies from your other managed assemblies is because it the default assemblies are built last, and that referencing them would create a circular reference. Setting up an assembly definition file marked as a test assembly should automatically configure the assembly to depend on the default assemblies. I have trouble imagining a scenario where this would be undesireable, or that this would be technically infeasible for unity to implement.
@Bit_Rot_1 What do you consider a “default” assembly? The second you add asmdef to a project you should not think in terms of “Assembly-CSharp.csproj”, “Assembly-CSharp-Plugins.csproj” and completly switch to asmdef and then there is nothing like a “default” assembly.
It is undesireable for any large project which actually uses asmdef to reduce compilation times (if it would work - in our case everything is always recompiled for some weird reason). Why would I want to recompile my tests if I have not changed ANYTHING it tests?
Technically it would be easy to reference all non-editor non-test assemblies from your Test.asmdef - as long as they share the included platform- and and do the same for Test.Editor assemblies but that covers only 2 scenarios and by far not all scenarios you can have .
Im strongly against making “reference everything” a default. What I really want is that they fix that only what is affected by a change recompiles and that the IDEs can handle asmdef files and that the workflow is faster. Doing anything with an asmdef in the inspector is really annoying and slow at the moment. If Unity would not stupidly and forceful overwrite .csproj references but would add entries to .asmdef references if they detect a referenced assembly stems from an asmdef all IDEs could add references much more quickly.
I advise against mixing the old and the new approach - even if you pack everything in 4 asmdef which mimic the old behaviour 1:1.
I mixed up my terminology a bit - looks like the term is “Predefined Assembly” - and yes, I am referring specifically to Assembly-CSharp and Assembly-CSharp-Editor.
I can see not wanting to reference the Predefined Assemblies from your Test Assemblies (if you are 100% managed, there’s probably nothing in the predefined assemblies anyway), but without having any way of doing so (regardless of whether the reference is made by default), incorporating ANY tests into your build FORCES you to use managed assemblies for your entire code base. This dependency seems avoidable and toxic - giving us a way to directly reference Predefined Assemblies from test assemblies solves the issue completely.
To your point, yes, in the scope of things, it isn’t that hard to make a few assembly definition files and link references where needed. However, the point stands that I should not have to explicitly manage my assemblies if I have no reason to other than the limitations imposed by unity’s test framework. The design is ill-conceived, and the problem is made worse by the fact that unity documentation mentions nothing of this issue.
To your point about selective compilation of assemblies (instead of compiling everything always), that sounds like a pretty bad issue, too. I’m not sure if you meant to imply that the two issues are mutually exclusive - in my eyes both issues are independent and worthy of attention.
@Bit_Rot_1 there should not be any predefined left - as they are empty - when you completly switch to asmdef only - and that is what I recommended above.
Yes both issues are independent technically, but it makes a huge difference when considering if I want to use the system
I have a test project with lots of imports all under Assets, plus my own, and I want to try out the Test Runner.
So I need to either move all the imports into a common folder and create an assembly reference (which will probably break something in the import process). Or create assembly references on all the import folders, along with my own assets and more maintenance.
I don’t particularly want to rework all this just to try the test runner.
This is a real headache for no reason when I could just reference Assembly-CSharp, but you don’t appear to support it?
I understand the desire for a well segregated architecture but you shouldn’t reduce the flexibility and productivity of your platform for it.
This is a bit tedious. Unityshould not forceyou to comply with a managed Assembly Defined hierarchy.
It would make a lot more sense if the test assemblies were compiled after the predefined assemblies. Then you could simply reference the predefined assemblies (and compile your test scripts every time you change your project scripts) or alternatively a specific assembly (compile your test scripts only when the targeted assembly is changed).
You can already partially do this by placing your editmode test files within the Editor folder (provided it’s under the default Assembly-CSharp-Editor.dll). Maybe I’m missing something, but this seems like a far better solution to the current implementation.
