Unity-Technologies / com.unity.netcode.gameobjects

Netcode for GameObjects is a high-level netcode SDK that provides networking capabilities to GameObject/MonoBehaviour workflows within Unity and sits on top of underlying transport layer.
MIT License
2.11k stars 431 forks source link

Can't import Unity.Netcode.TestHelpers.Runtime #2552

Open KenjiTakahashi-Rial opened 1 year ago

KenjiTakahashi-Rial commented 1 year ago

Description

Hi, I'm trying to use the NetcodeIntegrationTest class, which is in the Unity.Netcode.TestHelpers.Runtime namespace. When I try to import the namespace, I get an error that TestHelpers does not exist in the Unity.Netcode namespace.

I referenced the com.unity.netcode.testhelpers.runtime assembly in my .asmdef

Reproduce Steps

  1. Create an Assembly Definition Asset
  2. Add the reference com.unity.netcode.testhelpers.runtime
  3. Create a script in the same directory
  4. Try to import Unity.Netcode.TestHelpers.Runtime

Actual Outcome

The namespace cannot be imported because the reference is not present in the project references

Expected Outcome

The namespace can be imported and the reference is present in the project references

Screenshots

asmdef

Environment

Additional Context

The .cs files are visible in Library\PackageCache\com.unity.netcode.gameobjects@1.4.0\TestHelpers\Runtime, but Unity never builds a .dll and puts it in Library/ScriptAssemblies

Maclay74 commented 1 year ago

I had the same problem when I tried to write some tests for my code.

When I tried to find any information about writing tests for NGO, I didn't find a thing. I ended up reading existing tests and tried to come up with something similar, but faced the problem.

I think the issue is little more broad - NGO isn't ready for writing external functional tests, from both tools and documentation points of view. And I think a lot of people would appreciate it.

ShadauxCat commented 1 year ago

@Maclay74 basically hit on the thing: At the current time, our test infrastructure isn't designed with the idea of being used externally. It's there for us to test SDK code and we don't provide support for it at the same level we do for the SDK - for example, we don't follow semver standards for our test code because we treat it as internal code. A lot of it is public, but probably shouldn't be since we're not supporting it, so that makes it sort of a "use at your own risk" sort of deal - we don't provide any documentation and that code could break at any time. The NetcodeIntegrationTest base class could be entirely deleted in a future release (we don't have plans to do this but that doesn't mean it won't happen).

There are a couple of things I could potentially suggest that might fix your problem... but at the current time I don't think I can recommend trying to approach things by using our test infrastructure, simply because we're not currently building it with the intention of being used externally and that's likely to cause more pain than anything. I do think there is some value in providing something for this purpose in the future, but it's not something we have right now.

NoelStephensUnity commented 1 year ago

@Maclay74 Wanted to follow up on this as most of what @ShadauxCat said is definitively true regarding the lack of documentation and support for our tests. However, you can use our testing tools by creating a test assembly folder and making sure you have the right libraries included. image Here is an example project that should provide you with the correct settings to check against your project: NGOProjectWithTesting.zip

When you open TestRunner in the above provided example project, select the PlayMode/Runtime tests, and run the "Tests" assembly set. You should see all tests pass: image

The "trick" to this is that you can't use the package but need to use the branch of the package version you want to test against. From the example project provided above, the manifest entry for com.unity.netcode.gameobjects points to the release/1.4.0 branch: image If you want to just copy and paste here that is: "com.unity.netcode.gameobjects": "https://github.com/Unity-Technologies/com.unity.netcode.gameobjects.git?path=com.unity.netcode.gameobjects#release/1.4.0",

Just a reminder, like @ShadauxCat had noted, the TestHelpers assembly is "what it is" and there are plenty of existing NGO tests to get an idea of how to write your own (plus a bunch of the TestHelpers API does have comments to explain some of the basic functionality. If you run into issues, feel free to post a support issue here (but also be patient as we most likely won't place that at the top of the queue.).

You can see some of the API for the TestHelpers assembly here, and note that the example test project included above uses the IntegrationTestWithApproximation class that derives from the NetcodeIntegrationTest class (i.e. if you need specialized functionality you might derive from either of those two classes and make your own version.

Happy Testing! 👍 😸

Maclay74 commented 1 year ago

@ShadauxCat @NoelStephensUnity thanks for the explanation and the example!

NoelStephensUnity commented 1 year ago

@Maclay74 @KenjiTakahashi-Rial As a side note, I wasn't 100% correct and there is a way to use just the package and expose testables.

Sorry for not including this option, but as an alternate way you can add a "testables" entry to your manifest file just after the dependencies section:

{
  "dependencies": {
(all of your project's package dependencies) 
},
  "testables": [
    "com.unity.netcode.gameobjects"
  ]
}

This should also work when using the NGO package (and not have to point to the release branch).