1. 项目概述：为什么Unity单元测试是开发者的“安全带”

在Unity项目开发中，尤其是当项目规模膨胀到几十万行代码、涉及多个系统模块时，最让人头疼的莫过于“牵一发而动全身”。你只是修改了一个看似无关紧要的数值计算函数，结果游戏在某个特定关卡直接崩溃，或者某个UI的交互逻辑变得诡异。这种问题在开发后期，甚至是上线后暴露出来，修复成本会指数级上升。单元测试，就是为你的代码系上的一条“安全带”，它能在你每次修改代码后，自动验证核心逻辑的正确性，防止低级错误蔓延。

Unity 2019.3.x是一个长期支持版本，至今仍有大量项目基于此版本开发。其内置的测试框架基于NUnit，但很多开发者，尤其是从其他引擎或纯后端转过来的朋友，对如何在Unity中有效地编写和运行测试感到困惑。最大的两个“坑”莫过于Edit Mode测试和Play Mode测试的区别与应用场景。网上资料要么过于零散，要么版本老旧，照着做常常会遇到各种稀奇古怪的报错，比如“找不到TestRunner”、“PlayMode测试无法启动”或者“依赖的MonoBehaviour在Edit Mode下无法实例化”。

这篇文章，我将结合在多个中大型Unity项目中推行单元测试的实战经验，为你梳理一套从环境配置、测试编写、到两种模式（Edit Mode & Play Mode）下的实战技巧与避坑指南。目标不是让你成为测试理论专家，而是让你能立刻上手，为你的项目建立起第一道可靠的防线。

2. 环境准备与测试框架初探

在开始编写测试之前，确保你的Unity环境已经正确配置。Unity 2019.3.x默认已经集成了测试运行器，但我们需要对其进行一些了解和设置。

2.1 启用Test Runner窗口

首先，打开Unity编辑器，在顶部菜单栏选择Window > General > Test Runner。这会打开Test Runner窗口。这个窗口是你的测试命令中心，在这里你可以看到所有的测试用例，并运行它们。

Test Runner窗口通常有两个标签页：

• EditMode： 用于运行在编辑器环境下、不进入播放模式的测试。适合测试纯C#逻辑、工具类、数据结构和不依赖于Unity引擎生命周期（如Update、Start）的脚本。
• PlayMode： 用于运行需要启动Unity播放模式的测试。适合测试依赖于MonoBehaviour生命周期、物理系统、输入系统或需要实际游戏对象在场景中交互的代码。

注意：初次打开时，如果项目里还没有任何测试，或者测试程序集没有正确引用，列表可能是空的。你需要先创建测试程序集。

2.2 创建测试程序集

为了提高测试的隔离性和编译速度，最佳实践是将测试代码放在独立的程序集中。Unity通过程序集定义文件来管理。

1. 在Project窗口中，在你希望存放测试代码的文件夹上右键（例如，在Assets下创建Tests文件夹）。
2. 选择Create > Testing > Tests Assembly Folder。Unity会自动做几件事：
   • 创建一个名为Tests的文件夹（如果你选的是其他名字，则以此为准）。
   • 在该文件夹内创建一个名为Tests.asmdef的程序集定义文件。
   • 创建一个Editor子文件夹，并在其中创建Tests.Editor.asmdef文件。

这里的关键在于理解这两个.asmdef文件的用途：

• Tests.asmdef： 这个程序集可以包含Play Mode测试。因为它不放在Editor文件夹下，所以其中的代码可以被构建到最终的游戏包中（尽管测试代码通常不会被打包）。它的平台兼容性设置更广。
• Tests.Editor.asmdef： 这个程序集专门用于Edit Mode测试。因为它位于Editor文件夹内，所以其中的代码只能在Unity编辑器环境下运行，不会被包含在游戏构建中。这保证了测试工具和代码不会污染运行时。

为什么这么分？这是第一个容易踩的坑。如果你把Play Mode测试代码错误地放在了Editor文件夹下的程序集里，那么这些测试将无法访问某些运行时才存在的类型和API（比如一些仅在Standalone或Android平台下存在的类），导致编译错误。反之，如果把Edit Mode测试放在非Editor程序集，虽然可能能运行，但会破坏隔离性，且可能无意中将编辑器专用代码打包。

我的建议是：严格遵守这个结构。在Tests根文件夹下放Play Mode测试，在Tests/Editor下放Edit Mode测试。分别引用对应的程序集定义文件。

2.3 核心命名空间与特性

Unity测试基于NUnit框架。你需要熟悉以下几个核心命名空间和特性：

using NUnit.Framework; // 核心断言和测试特性 using UnityEngine; // 访问Unity对象 using UnityEngine.TestTools; // Unity特定的测试工具和特性（如`UnityTest`）

常用的NUnit特性：

• [Test]: 标记一个普通的测试方法。可用于Edit Mode和Play Mode。
• [UnityTest]: Unity特有的特性，用于标记一个协程测试方法。这是支持yield语句、可以等待多帧或异步操作的关键，主要用于Play Mode测试。
• [SetUp]/[TearDown]: 在每个测试方法运行之前/之后执行。用于初始化测试环境和清理。
• [OneTimeSetUp]/[OneTimeTearDown]: 在整个测试类中所有测试开始前/结束后执行一次。适合重量级的初始化，如创建临时资源。
• [TestCase]/[TestCaseSource]: 为测试方法提供多组参数，实现参数化测试。

3. Edit Mode测试实战：聚焦纯逻辑与工具函数

Edit Mode测试运行速度快，不启动游戏，是验证业务逻辑、工具函数、数据模型的首选。它的核心原则是：避免依赖Unity引擎的运行时环境。

3.1 一个典型的Edit Mode测试案例

假设我们有一个负责计算伤害的工具类DamageCalculator：

// Assets/Scripts/Combat/DamageCalculator.cs public static class DamageCalculator { public static float CalculateFinalDamage(float baseDamage, float attackerAttack, float defenderDefense, float criticalChance) { if (criticalChance < 0 || criticalChance > 1) throw new ArgumentOutOfRangeException(nameof(criticalChance), "Critical chance must be between 0 and 1."); float defenseFactor = Mathf.Clamp(1 - defenderDefense / (defenderDefense + 100), 0.2f, 0.8f); float damage = baseDamage * attackerAttack * defenseFactor; bool isCritical = UnityEngine.Random.value < criticalChance; // 注意这里使用了UnityEngine.Random if (isCritical) { damage *= 1.5f; } return damage; } }

为它编写Edit Mode测试：

// Assets/Tests/Editor/Combat/DamageCalculatorTests.cs using NUnit.Framework; using UnityEngine; public class DamageCalculatorTests { [Test] public void CalculateFinalDamage_DefenseFactorIsClamped() { // 防御极高时，减伤不应低于20% float damage = DamageCalculator.CalculateFinalDamage(100f, 1f, 10000f, 0f); // 基础100 * 攻击1 * 最小防御因子0.2 = 20 Assert.AreEqual(20f, damage, 0.01f); // 使用delta处理浮点数精度 // 防御极低时，减伤不应高于80% damage = DamageCalculator.CalculateFinalDamage(100f, 1f, 0f, 0f); // 基础100 * 攻击1 * 最大防御因子0.8 = 80 Assert.AreEqual(80f, damage, 0.01f); } [TestCase(0.0f)] [TestCase(0.5f)] [TestCase(1.0f)] public void CalculateFinalDamage_CriticalChanceWithinRange_DoesNotThrow(float validChance) { // 测试边界和中间值是否抛出异常 Assert.DoesNotThrow(() => DamageCalculator.CalculateFinalDamage(100f, 1f, 50f, validChance)); } [Test] public void CalculateFinalDamage_CriticalChanceOutOfRange_ThrowsException() { // 测试非法参数抛出特定异常 var ex = Assert.Throws<System.ArgumentOutOfRangeException>( () => DamageCalculator.CalculateFinalDamage(100f, 1f, 50f, 1.5f) ); // 可选：进一步断言异常信息 StringAssert.Contains("Critical chance must be between 0 and 1", ex.Message); } }

3.2 Edit Mode测试的“坑”与技巧

坑1：UnityEngine.Random的不可控性注意上面的DamageCalculator使用了UnityEngine.Random.value。在Edit Mode测试中，这会产生随机结果，导致测试有时通过有时失败（Flaky Test）。这是大忌。

解决方案：使用测试替身或注入随机种子。

• 方法A（推荐）：重构代码以支持依赖注入。将随机数生成抽象为一个接口，在测试时注入一个可控的“伪随机”实现。

  public interface IRandomProvider { float Value { get; } } public class SystemRandomProvider : IRandomProvider { public float Value => UnityEngine.Random.value; } public class MockRandomProvider : IRandomProvider { public float Value { get; set; } } // 修改DamageCalculator，通过构造函数或静态属性接收IRandomProvider // 在测试中，注入一个MockRandomProvider并设置Value为特定值（如0.3）来模拟暴击。

• 方法B（快速但粗糙）：在测试开始时设置随机种子。UnityEngine.Random.InitState(12345);这能保证单次测试运行结果一致，但不同测试间如果都依赖随机，可能会相互干扰。

坑2：测试依赖于ScriptableObject或Resources加载如果你的函数内部使用了Resources.Load或需要访问项目中的ScriptableObject资产，在Edit Mode测试中可能会因为路径问题失败。

解决方案：使用AssetDatabase在测试准备阶段创建临时资产。

[OneTimeSetUp] public void OneTimeSetUp() { // 创建一个临时的ScriptableObject用于测试 var tempSO = ScriptableObject.CreateInstance<MyConfigSO>(); tempSO.someValue = 10; // 将其保存到临时路径 AssetDatabase.CreateAsset(tempSO, "Assets/Tests/Temp/TempConfig.asset"); AssetDatabase.SaveAssets(); } [OneTimeTearDown] public void OneTimeTearDown() { // 删除临时资产，保持项目清洁 AssetDatabase.DeleteAsset("Assets/Tests/Temp/TempConfig.asset"); }

注意：AssetDatabase是编辑器API，所以这类测试必须放在Editor文件夹下的程序集中。

技巧：充分利用[SetUp]和[TearDown]对于每个测试都需要的新鲜环境，比如创建一个新的GameObject并挂载测试组件，应该在[SetUp]中完成，并在[TearDown]中立即销毁，防止测试间残留对象相互影响。

public class MyMonoBehaviourTest { private GameObject testGo; private MyComponent comp; [SetUp] public void SetUp() { testGo = new GameObject("TestObject"); comp = testGo.AddComponent<MyComponent>(); } [TearDown] public void TearDown() { Object.DestroyImmediate(testGo); // Edit Mode下使用DestroyImmediate } [Test] public void TestComponentInitialization() { Assert.IsNotNull(comp); // ... 测试逻辑 } }

4. Play Mode测试实战：模拟运行时与集成测试

当你的代码与MonoBehaviour生命周期、协程、物理、UI事件或输入系统紧密耦合时，Edit Mode测试就力不从心了。这时就需要Play Mode测试。它会在一个独立的、隐藏的游戏视图中运行你的测试，模拟真实的游戏环境。

4.1 编写第一个Play Mode测试

假设我们有一个PlayerController，它需要在Update中处理移动：

// Assets/Scripts/Player/PlayerController.cs public class PlayerController : MonoBehaviour { public float speed = 5.0f; private CharacterController characterController; void Start() { characterController = GetComponent<CharacterController>(); if (characterController == null) { Debug.LogError("CharacterController component is missing!"); } } void Update() { float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); Vector3 move = new Vector3(horizontal, 0, vertical) * speed * Time.deltaTime; characterController.Move(move); } }

为它编写Play Mode测试，我们需要使用[UnityTest]特性，并以协程的形式运行：

// Assets/Tests/Player/PlayerControllerTests.cs (注意：不在Editor文件夹内！) using System.Collections; using NUnit.Framework; using UnityEngine; using UnityEngine.TestTools; public class PlayerControllerTests { [UnityTest] public IEnumerator PlayerMovesWithInput() { // 1. 在测试中创建游戏对象和组件 GameObject playerGo = new GameObject("Player"); var controller = playerGo.AddComponent<PlayerController>(); playerGo.AddComponent<CharacterController>(); // 必须添加依赖组件 controller.speed = 5.0f; // 记录初始位置 Vector3 startPos = playerGo.transform.position; // 2. 模拟输入 - 这是Play Mode测试的关键和难点！ // 注意：直接设置Input.GetAxis在2019.3.x中很难模拟。 // 更佳实践是重构代码，将输入抽象为一个服务（如IInputService）， // 在测试中注入一个模拟输入。这里为了演示，我们使用一个“后门”或反射来设置。 // 假设我们修改了PlayerController，使用一个可测试的输入包装器。 // 此处简化，我们先跳过输入模拟，测试无输入时是否不动。 // 3. 等待几帧，让Update执行 yield return new WaitForSeconds(0.1f); // 等待0.1秒，约6帧 // 4. 断言：在没有模拟输入的情况下，玩家位置不应改变 Assert.AreEqual(startPos, playerGo.transform.position); // 5. 清理（可选，因为PlayMode测试环境通常会为每个测试方法重启） // Object.Destroy(playerGo); } }

4.2 Play Mode测试的核心挑战与解决方案

挑战1：模拟输入（Input）Unity的Input类是静态的，在测试中极难模拟。上面的测试实际上避开了这个问题。正确的做法是“依赖注入”：

1. 创建输入接口：

   public interface IPlayerInput { float GetHorizontal(); float GetVertical(); }

2. 创建真实实现（用于游戏运行时）：

   public class UnityPlayerInput : IPlayerInput { public float GetHorizontal() => Input.GetAxis("Horizontal"); public float GetVertical() => Input.GetAxis("Vertical"); }

3. 修改PlayerController，依赖接口：

   public class PlayerController : MonoBehaviour { public float speed = 5.0f; private CharacterController characterController; private IPlayerInput playerInput; // 依赖接口 void Start() { characterController = GetComponent<CharacterController>(); // 默认使用Unity输入，但允许外部设置（用于测试） if (playerInput == null) playerInput = new UnityPlayerInput(); } public void SetPlayerInput(IPlayerInput input) // 提供注入方法 { playerInput = input; } void Update() { float horizontal = playerInput.GetHorizontal(); // 使用接口 float vertical = playerInput.GetVertical(); Vector3 move = new Vector3(horizontal, 0, vertical) * speed * Time.deltaTime; characterController.Move(move); } }

4. 在测试中注入模拟输入：

   [UnityTest] public IEnumerator PlayerMovesRight_WhenHorizontalInputIsPositive() { GameObject playerGo = new GameObject("Player"); var controller = playerGo.AddComponent<PlayerController>(); playerGo.AddComponent<CharacterController>(); controller.speed = 5.0f; // 创建模拟输入 var mockInput = new MockPlayerInput { horizontal = 1.0f, vertical = 0.0f }; controller.SetPlayerInput(mockInput); // 注入！ Vector3 startPos = playerGo.transform.position; yield return new WaitForSeconds(0.5f); // 移动半秒 Vector3 endPos = playerGo.transform.position; Assert.Greater(endPos.x, startPos.x); // X坐标应该增加 // 可以更精确地计算预期移动距离：5.0f * 1.0f * 0.5f = 2.5f Assert.AreEqual(startPos.x + 2.5f, endPos.x, 0.1f); // 考虑物理引擎等微小误差 } class MockPlayerInput : IPlayerInput { public float horizontal = 0f; public float vertical = 0f; public float GetHorizontal() => horizontal; public float GetVertical() => vertical; }

挑战2：测试异步操作与协程[UnityTest]方法返回IEnumerator，让你可以使用yield语句来等待。这是测试协程、动画、网络请求等异步操作的利器。

[UnityTest] public IEnumerator HealthComponent_Dies_WhenHealthReachesZero() { var go = new GameObject(); var health = go.AddComponent<Health>(); health.currentHealth = 10; health.maxHealth = 10; bool deathEventFired = false; health.OnDeath += () => deathEventFired = true; health.TakeDamage(10); // 假设这个方法内部可能会触发一个死亡动画协程 // 等待几帧，给事件触发或协程完成留出时间 yield return null; // 等待一帧 yield return new WaitForSeconds(0.5f); // 或者等待一段时间 Assert.IsTrue(deathEventFired); Assert.IsTrue(health.IsDead); }

挑战3：测试场景与对象生命周期Play Mode测试默认会为一个测试方法创建一个干净的、空白的场景。测试结束后，这个场景会被销毁。这意味着你不需要（也不应该）在[TearDown]中手动销毁通过new GameObject()创建的对象，因为它们属于这个临时场景，会随场景一起销毁。手动销毁反而可能导致错误。

但是，如果你通过AssetDatabase在测试中创建了持久化资产（如ScriptableObject资产文件），则必须在[OneTimeTearDown]中清理，就像在Edit Mode测试中一样。

5. 高级技巧与测试策略

5.1 使用[UnityPlatform]进行平台相关测试

如果你的代码在不同平台（如Editor、Standalone、Android）上有不同行为，可以使用[UnityPlatform]特性来限制或包含特定平台的测试。

using UnityEngine.TestTools; [Test] [UnityPlatform(RuntimePlatform.WindowsEditor, RuntimePlatform.OSXEditor)] public void SomeEditorOnlyFeatureTest() { // 这个测试只会在Windows或Mac的编辑器下运行 Assert.IsTrue(Application.isEditor); } [Test] [UnityPlatform(exclude = new[] { RuntimePlatform.Android })] public void TestExcludingAndroid() { // 这个测试不会在Android平台上运行 Assert.IsFalse(Application.platform == RuntimePlatform.Android); }

5.2 利用Assert.That语法与自定义约束

NUnit提供了更现代、可读性更强的Assert.That语法，并支持丰富的约束条件。

[Test] public void TestWithThatSyntax() { int[] numbers = new int[] { 1, 2, 3, 4, 5 }; // 传统语法 Assert.AreEqual(5, numbers.Length); Assert.Contains(3, numbers); // That语法，更接近自然语言 Assert.That(numbers, Has.Length.EqualTo(5)); Assert.That(numbers, Has.Member(3)); Assert.That(numbers, Is.All.GreaterThan(0)); // 所有元素大于0 Assert.That(2 + 2, Is.EqualTo(4).Within(0.01)); // 浮点数比较带容差 }

5.3 测试私有方法：是福是祸？

通常，单元测试应专注于公共接口（公有方法和属性）。但有时，一个复杂的私有方法包含了重要逻辑，直接测试公共方法路径覆盖不全。这时，有几种选择：

1. 不测试私有方法：通过测试调用它的公有方法来间接覆盖。如果覆盖不到，说明这个私有方法可能可以被提取到一个独立的公有类中。

2. 使用InternalsVisibleTo属性：将待测试程序集（你的游戏代码程序集）的内部（internal）成员对测试程序集可见。

   • 在游戏代码程序集的AssemblyInfo.cs（或.asmdef的Assembly Definition References中）添加：

     [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("YourGame.Tests.Editor")] [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("YourGame.Tests")]

   • 然后将你想测试的私有方法改为internal。
   • 优点：保持了代码的封装性（对游戏其他部分仍是私有），同时允许测试访问。
   • 缺点：修改了生产代码结构来适应测试。

3. 使用反射（不推荐）：在测试中使用反射调用私有方法。这会使测试变得脆弱（方法名更改会导致测试失败），且代码丑陋。

我的建议：优先考虑重构代码设计（将复杂私有逻辑提取到公共工具类），其次考虑使用InternalsVisibleTo。尽量避免使用反射。

5.4 测试覆盖率与持续集成

编写测试不是终点，确保测试有效运行并监控覆盖率才是关键。

• Unity Test Runner：可以生成简单的测试结果报告。
• 第三方工具：如Unity Test Framework（UTF）本身支持与OpenCover等工具集成来生成代码覆盖率报告。在Unity 2019.3中，可能需要通过Package Manager安装Code Coverage预览包（如果可用），或使用外部工具。
• 持续集成（CI）：在Jenkins、GitLab CI、GitHub Actions等CI服务器上自动运行Unity测试。你需要使用命令行来运行Unity并执行测试。

  # 一个基本的命令行示例（路径需根据实际情况调整） /path/to/Unity -runTests -batchmode -projectPath /path/to/your/project -testResults /path/to/results.xml -testPlatform editmode

  • -runTests：执行测试。
  • -batchmode：批处理模式，无图形界面。
  • -testPlatform：指定editmode或playmode。
  • -testResults：指定测试结果输出文件。

6. 常见问题排查与实战心得

6.1 测试列表为空或找不到测试

• 检查程序集定义引用：确保你的测试脚本所在的程序集（.asmdef文件）正确引用了必要的程序集。Edit Mode测试程序集需要引用UnityEditor.TestRunner和UnityEngine.TestRunner。Play Mode测试程序集需要引用UnityEngine.TestRunner。同时，两者都需要引用你的游戏代码程序集和NUnit（通常通过引用UnityEngine.TestRunner间接引入）。
• 检查脚本编译错误：如果测试脚本本身有编译错误，它不会出现在Test Runner中。查看Console窗口是否有错误。
• 点击“Rebuild”：在Test Runner窗口的顶部，有一个“Rebuild”按钮，点击它可以强制刷新测试列表。

6.2 Play Mode测试卡住、不启动或无限期运行

• 检查[UnityTest]协程是否正常结束：确保你的IEnumerator方法最终会执行完所有yield语句并返回。如果协程里有一个无限循环的while(true)且没有yield，测试就会挂起。
• 避免在[SetUp]中使用[UnityTest]：[SetUp]和[TearDown]方法不能是协程。如果需要在Play Mode测试的准备工作中有异步操作，考虑在测试方法内部完成，或者使用[UnitySetUp]特性（但需注意其生命周期）。
• 超时设置：NUnit的[Timeout]特性在[UnityTest]中可能行为不一致。如果测试真的卡住，需要手动检查逻辑。

6.3 “多个测试同时运行”导致的干扰

默认情况下，Unity Test Runner会按顺序运行测试。但如果你手动编写了多线程代码，或者在Play Mode测试中创建了不会自动销毁的全局静态对象，可能会造成测试间的状态污染。

• 隔离静态状态：如果测试修改了静态变量或单例，在[TearDown]中将其重置为初始状态。
• 使用[UnitySetUp]和[UnityTearDown]：对于Play Mode测试，如果[SetUp]/[TearDown]中需要用到yield（例如加载一个测试场景），可以使用[UnitySetUp]和[UnityTearDown]，它们也是协程。

6.4 测试运行速度慢

• 区分Edit Mode和Play Mode：将不依赖运行时的测试全部移到Edit Mode，它们的运行速度比Play Mode快一个数量级。
• 避免在每次测试中加载大型资源：使用[OneTimeSetUp]来加载一次共享的、只读的资源。对于需要修改的资源，如果必须每个测试独立，考虑使用内存中的模拟对象而非从磁盘加载。
• 精简Play Mode测试场景：如果测试需要特定场景，创建一个只包含必要元素的最简场景。

6.5 个人实战心得

1. 测试驱动开发（TDD）在Unity中可行，但有难度：由于引擎依赖和MonoBehaviour的生命周期，纯TDD可能比较笨重。我采用的是一种“测试助力开发”的模式：先写一个功能的最小实现，然后立刻为它的核心逻辑编写测试（尤其是Edit Mode测试），再重构和扩展功能，同时补充测试。对于Play Mode部分，更多是在功能模块完成后，编写集成测试来验证整体行为。
2. Mock和Stub是你的好朋友：花时间设计可测试的架构（依赖注入、接口分离）所付出的成本，远低于后期调试不可测代码的成本。一开始可能会觉得繁琐，但一旦习惯，代码质量和开发信心会大幅提升。
3. 不要追求100%覆盖率，追求核心逻辑覆盖率：UI动画、纯粹的视觉效果、第三方插件封装层，这些地方很难写测试，性价比也低。优先保证游戏状态机、核心算法、数据管理、网络消息处理等关键部分的测试覆盖。
4. 让测试成为CI/CD流水线的一环：每次提交代码后自动运行测试，如果测试失败，合并请求就不能通过。这能有效防止“它在我机器上是好的”这类问题。
5. 测试代码也是代码，需要维护：当生产代码变更时，记得更新测试。陈旧的、失败的测试会迅速失去团队的信任，最终被所有人忽略。保持测试的清洁和有效。