Adding tests to a package

As with any kind of development, it is good practice to add tests to your package. There are three things you must do in order to set up tests on your package:

Create the C# test files and put them under the Tests folder.
Create asmdef files for your tests.
Enable tests for your package.

Location of test files

You can add your test files to the Tests folder of your package in the Editor and Runtime subfolders. For example, a simple package with tests might look something like this:

MyPackage
  ├── package.json
  ├── Editor
  │     ├── MyPackage.Editor.asmdef
  │     └── EditorExample.cs
  ├── Runtime
  │     ├── MyPackage.Runtime.asmdef
  │     └── RuntimeExample.cs
  └── Tests
        ├── Editor
        │    ├── MyPackage.EditorTests.asmdef
        │    └── EditorExampleTest.cs
        └── Runtime
             ├── MyPackage.RuntimeTests.asmdef
             └── RuntimeExampleTest.cs

Each of those subfolders must contain an .asmdef file, which provides references to the Editor and Runtime assemblies. The assembly definition files also provide a reference to the test assembly files. For more information, see Assembly definition files for tests.

Assembly definition files for tests

You can edit assembly definition files directly. You need to make sure to add the following references:

Attribute	Type	Description
name	Строка (String)	The name of the assembly without the file extension.
references	Array of Strings	References to the Editor and Runtime assemblies. Assembly definition files require different references depending on whether it is for Editor or Runtime tests: - For Editor tests, add a reference to the package’s Editor and Runtime assemblies. - For Runtime tests, add a reference to the package’s Runtime assembly only.
optionalUnityReferences	Array of Strings	This list of Unity references must include “TestAssemblies” in order to mark the assembly as a test assembly. This adds references to the unit.framework.dll and UnityEngine.TestRunner.dll libraries to the Assembly Definition.
includePlatforms	Array of Strings	For the Editor test, this list of platforms must include the “Editor” platform.

Tip: You can also edit the assembly definition files in the Inspector. See Assembly Definitions for more information.

Editor file example

The editor test .asmdef file should look like this:

{
  "name": "MyPackage.Editor.Tests",
  "references": [
    "MyPackage.Editor",
    "MyPackage"
  ],
  "optionalUnityReferences": [
    "TestAssemblies"
  ],
  "includePlatforms": [
    "Editor"
  ],
  "excludePlatforms": []
}

Runtime file example

The runtime test .asmdef file should look like this:

{
  "name": "MyPackage.Tests",
  "references": [
    "MyPackage"
  ],
  "optionalUnityReferences": [
    "TestAssemblies"
  ],
  "includePlatforms": [],
  "excludePlatforms": []
}

Enabling tests for a package

For embedded packages, you don’t need to explicitly enable tests because embedded packages are in development.

However, for other types of dependencies, you need to add the testables attribute to the Project manifest and add the names of packages that have tests you want to run. That includes direct and indirect dependencies of the Project. For example:

{
  "dependencies": {
    "com.unity.some-package": "1.0.0",
    "com.unity.other-package": "2.0.0",
    "com.unity.yet-another-package": "3.0.0",
  },
  "testables": ["com.unity.some-package", "com.unity.other-package"]
}

This example adds tests for the com.unity.some-package and com.unity.other-package packages in Unity’s Test Framework package.

NOTE: You may need to re-import the package, because the test framework doesn’t always immediately pick up changes to the testables attribute.

Package layout

Package manifest

Manual