Skip to content

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

@trudeaua21

Description

@trudeaua21

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions