Extending Unity Test Framework

[Warnecke]

In version 1.1.0 of the Unity Test Framework (UTF) we have introduced multiple ways of extending the UTF functionality to help you customize the framework to suit your CI needs.

We have gathered some of the ways that UTF can be extended in our documentation here: Extending Unity Test Framework | Test Framework | 1.1.33

One of the bigger changes is the TestRunnerApi. This allows for running tests programmatically from code running in the Unity editor. You can also get the test list on beforehand and get callbacks with test results.

One extension we have added is the ability to customize the build settings when building the player for tests. It is possible to combine this with callbacks on the player to split the building of the player and running the tests. This is especially useful when you want to run tests on a device, as you can avoid blocking that device while building the player. You can then also customize the way that you report back the test results. .

See the documentation on the callbacks here: TestPlayerBuildModifier attribute | Test Framework | 1.1.33

Some minor improvements include new edit mode yield commands for recompiling scripts and for waiting for a domain reload.

[liortal]

I think I asked this before but trying again - will this ITF package support 2018.4 versions as well?

We only recently upgraded and it is a process we don’t do so often. I would love to benefit from the test framework updates as well.

[Warnecke]

@liortal

I think I asked this before but trying again - will this ITF package support 2018.4 versions as well?

We only recently upgraded and it is a process we don’t do so often. I would love to benefit from the test framework updates as well.

I am afraid not. It is not possible for us to backport the full package to 2018.4, as it would collide with the build in version. There is currently no plans for backporting the TestRunnerApi to 2018.4 either.

[liortal]

@Warnecke

I am afraid not. It is not possible for us to backport the full package to 2018.4, as it would collide with the build in version. There is currently no plans for backporting the TestRunnerApi to 2018.4 either.

Does the package come in source code format?

If the only problem is colliding with the existing framework (and not relying on some deeper integration with the engine) I could simply change the namespace or something similar.

[Warnecke]

@liortal

Does the package come in source code format?

If the only problem is colliding with the existing framework (and not relying on some deeper integration with the engine) I could simply change the namespace or something similar.

You could try that. Make a 2019.2 project with the test-framework version you desire and then find the source code inside the PackageCache. You can then move the source inside the Packages folder of e.g. a 2018.4 project.
In addition to the namespace collisions, you might face some issues with changes to assembly definitions between 2018.4 and 2019.2.

[liortal]

@Warnecke

You could try that. Make a 2019.2 project with the test-framework version you desire and then find the source code inside the PackageCache. You can then move the source inside the Packages folder of e.g. a 2018.4 project.
In addition to the namespace collisions, you might face some issues with changes to assembly definitions between 2018.4 and 2019.2.

Sounds simple enough. I can post it later to gain instant internet fame!

[liortal]

@Warnecke turns out it is not that simple

As i thought, the test framework probably has some deeper dependencies on class introduces in newer Unity versions (DeploymentTargetLogger?) so it will not even compile on Unity 2018.4.

[fherbst]

For extension needs - would be great if you can take a look at Ability to specify custom ChildTests / create hierarchies of tests programmatically , @Warnecke . Seems the extensibility docs are for “how to run tests from script”, not “how to add tests by script”.