Question How to access script from different Assembly in play mode testing?

Hello,
I am new with Unity test framework and have encountered a problem.
I want to access a script attached to a GameObject in the scene that I load in the beginning of the test.
The problem occurs in the bolded areas: The type or namespace name '****' could not be found (are you missing a using directive or an assembly reference?

How can I access methods in script attached to a gameObject in a scene I open with a test?
Thanks for the help


Code:
using System.Collections;
using System.Collections.Generic;
using NUnit.Framework;
using UnityEngine;
using UnityEngine.TestTools;
using UnityEngine.SceneManagement;
using UnityEngine.EventSystems;
using UnityEngine.UI;
using *name of my assembly

namespace Tests
{
public class Test1
{
private GameObject otherGameObject;
private MyScriptName myScriptName;

[UnityTest]
public IEnumerator Test1WithEnumeratorPasses()
{
SceneManager.LoadScene("NameOfMyScene");
yield return new WaitForSecondsRealtime(5);
otherGameObject = GameObject.Find("GameObjectWithScript");
myScriptName = otherGameObject.GetComponent<MyScriptName>();

yield return null;
}
}
}

 

But what if all of my code is under Assembly-CSharp. And I cant put my code under some other assembly.
Is it possible in that case?

 

Thank you for information

 

Any chance whatsoever that you'll consider supporting this? It turned out (for us at least) that the asmdef workflow was strictly worse in every single way than the "old" workflow, so after shipping a game with asmdefs, we've hard pivoted back and are much, much happier.

But it does makes testing a pain, since we can't access any of our code directly, and essentially end up having to rely on GetComponent(string) and reflection, which is annoying.

It would require being able to define that some assembly definitions run after the built-in rather than before, but really tests always need to be compiled last, and having a testing framework that says "the tests will be compiled before some of your code" is just silly.

 

There were simply no real benefits. We had this idea that we would be able to use them to help properly structure the game code, but it turned out that all of our systems kinda wanted to know about each other occasionally. So the task of figuring out which assemblies needed to exist, and which ones that needed to have dependencies to which ended up being very, very hard.

So they ended up having like 15 dependencies each, so our compile and enter play mode times got utterly trashed, and we very often had to make interfaces with a single implementation just to pass around data, or create events where we really should just be calling a method directly.

We should have backed out, but that ended up not being feasible for reasons that I can't quite remember - except that one of them was that we had a big unit testing suite that we'd just have to toss if we wanted to.

So they made the code harder to write, harder to read, and slower to compile. So pretty much exactly the inverse of the intention.

It's also just so much easier to just throw an editor folder in there and have it work the first time. With the asmdef workflow, we have to add the assembly definition, wait for the entire codebase to fail to recompile, add the correct dependencies and click all the correct checkboxes, and then get it to work. So adding editors to something that didn't use to have editors turned into a several minute process that had the possibility of making errors when doing instead of just making a damn folder.

We were super hyped about asmdefs. The idea was great on paper, so we bought in hard. The end result was three years of wasted effort in supporting a feature that slowed us down. We'd have been much happier as programmers if we'd just have skipped it.


These days I think the feature just doesn't have much merit inside a scripts folder. If there's a part of the project that's stable enough to pull out and turn into a dependency instead of something that's in flux, that becomes a package, no an assembly.

As of now, I consider rolling our own unit testing framework as less work than putting our code in asmdefs.

 

What we do is just have one very large assembly for most of our gameplay code, and only make separate asmdefs for other code that is clearly self-contained. That's worked out fine for tests so far, for us.

I do agree that more asmdefs = more problems. Games really don't want to be a DAG of dependencies, haha. We did it more fine-grained for a while, and it was clear that didn't work well.

 

Sorry for taking forever, but Case 1331217 has been posted.

As I stated in the bug report, If you take a step back and look at the situation, it's somewhat absurd to have a test framework for Unity that can't be used to test the default way of writing code for Unity.

 

Running into this issue now, very frustrating. A third-party tool which we are trying to extend to suit our own needs uses asmdef's whereas the bulk of our own code is written without the use of Assembly Definitions, which now results in us not being able to adjust the tools to our needs.

 

Still a problem. Sadly even cant be solved with an rsp.csc file, you get internal bee build errors while trying to include Assembly-Charp

 

It seems like this extra requirement is just not mentioned anywhere in the docs: https://docs.unity3d.com/Packages/com.unity.test-framework@1.4/manual/index.html