Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Support Package Testing for Packages with Dependencies Outside of the Unity Registry #225

Closed
trudeaua21 opened this issue Jun 10, 2023 · 1 comment · Fixed by #261
Labels
enhancement New feature or request

Comments

@trudeaua21
Copy link
Contributor

Context

In the testing for the initial release of package testing, the only package dependencies that were tested to work with the test runner were com.unity.inputsystem and com.unity.test-framework. From this, I sort of extrapolated that dependencies from the Unity Registry likely work fine with the test runner.

However, I never messed around with scoped registries, UPM, or Git dependencies. Therefore, support for those sorts of dependencies is undefined currently.

Suggested solution

It's possible that packages with dependencies outside of the Unity Registry are already supported. This could be tested in a couple of different ways.

First, if anyone out there has a package with any non-Unity Registry dependencies, you could try just running your tests with the test runner, and add a comment letting the maintainers know whether or not the test runner worked for you.

Alternatively, you could add a dependencies block to the package.json of unity-package-with-correct-tests which includes any dependencies that we aren't sure how the test runner would handle. Then, we could update the tests in unity-package-with-correct-tests to use those dependencies in such a way that the tests will fail if the dependencies don't resolve properly. After that, running the tests (for the test runner itself, not Unity tests) should be able to determine whether or not the test runner can handle certain kinds of dependencies. This might be worth it to add anyway, as it would make the testing for this action more robust.

If it's found that dependencies outside of the Unity Registry don't work, then I don't know what it would take to fix that, since I've never worked with any dependencies like that. However, there have been some ideas from the community, which I've included below.

Additional details
There's a lot of discussion of this in #164, but here are specific items I've pulled from that discussion:

Question on scoped registries by andywiecko

Summary of the problem and potential solution by myself

Idea from JesseTG to solve the scoped registries problem if it comes up.

@sdcinglis
Copy link

I experimented with this and for me the externally hosted package (hosted in GitHub) was not found. Presumably this is because there's no step to setup the scoped registries in the temp project. My current workaround is that in each package repository I define two folders. One contains the package itself, the other contains a simple project that references the package. Then I run the tests on that example project. I've already resolved all the authentication issues for the scoped registry there so I know it works in theory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants