一、单元测试的定义与作用
单元测试定义：单元测试在传统软件开发中是非常重要的工具，它是指对软件中的最小可测试单元进行检查和验证，一般情况下就是对代码中的一个函数去进行验证，检查它的正确性。一个单元测试是一段自动化的代码，这段代码调用被测试的工作单元，之后对这个单元的单个最终结果的某些假设进行检验。单元测试使用单元测试框架编写，并要求单元测试可靠、可读并且可维护。只要产品代码不发生变化，单元测试的结果是稳定的。（百度的）
单元测试可以让你在软件开发的早期阶段发现 Bug，而不必到集成测试的时候才发现，开发完成一个模块（类、函数）就对应地做一个单元测试，尽早发现并处理掉bug，提高代码的质量。（反正单元测试就是杠杠好！）
二、在Unity中使用NUnit进行单元测试
话说，马三在工作的过程中，极少地发现周围的同事会对自己编写功能进行单元测试。一般都是开发完功能以后，随便写两段测试的代码（有的甚至都不测一下），一看没有问题就丢到SVN或者Git仓库里面了。结果当游戏出包以后，测试团队总会反馈回很多完全可以提前规避掉的低级bug。当然可能他们本身没有单元测试的习惯或者由于活多、工期太紧等种种原因，才不做单元测试的。（活都要干不完了，还做毛测试，Delay不扣钱啊！？）
好了，闲话扯完该说说咱们这个单元测试了。单元测试目前有很多成熟的框架可以供我们使用，我比较推荐的就是Unity Editor自带的Editor Tests Runner，功能不多，但是已经够用了，使用也很方便。Editor Tests Runner是开源单元测试工具NUnit在Unity引擎中的实现，目前Unity中使用的NUnit版本是2.6.4。
Editor Tests Runner可以通过Window -> Editor Tests Runner菜单打开，它的样子如下图所示：
在这个窗口中显示了当前添加的单元测试用例，以及他们通过的情况。首先，你需要点击窗口左上角的Run All按钮来执行所有的单元测试。绿色的对号表示这个用例通过了单元测试，红色的禁止符号表示未通过单元测试。
下面我们来看一下如何编写单元测试的代码。单元测试代码和游戏运行时代码是分开保存的，它只在Editor环境下可用，因此你需要把它放到Editor目录下。
首先为了下面的测试，我们先定义一个自定义类型的错误异常，提前备用。只需要让它直接继承 ApplicationException 就可以了，代码如下所示：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
/// <summary>
/// 自定义的异常类型
/// </summary>
class NegativeHealthException : ApplicationException
{
}
下面编写我们的需要进行被测试的模块或者代码。假设游戏代码中存在一个Player类来代表主角色，里面有几个函数用来在玩家受到伤害时减少血量，或者通过药水回复血量。其中Damage函数写了三个版本，一个是正确的，两个是返回错误结果的。在正确的函数中，当 Health 的值小于 100 的时候，会抛出一个刚才我们自定义的异常。代码如下所示：
1 using System.Collections;
2 using System.Collections.Generic;
3 using UnityEngine;
4
5 public class Player{
6
7 public float Health { get; set; }
8
9 #region 正确的方法
10
11 public void Damage(float value)
12 {
13 Health -= value;
14 if (Health < 0)
15 {
16 throw new NegativeHealthException();
17 }
18 }
19
20 public void Recover(float value)
21 {
22 Health += value;
23 }
24 #endregion
25
26 #region 错误的方法
27
28 public void DamageWrong(float value)
29 {
30 Health -= value + 1;
31 }
32
33 public void DamageNoException(float value)
34 {
35 Health -= value;
36 }
37 #endregion
38 }
接着我们来编写单元测试代码。这里我们创建了一个叫做PlayerTest的类，里面写了两个函数分别代表两个测试用例。为了让Unity识别这两个函数是测试用例，我们需要在函数前加上 [Test] 的属性，这样所有带有 [Test] 属性的函数都会成为一个测试用例，代码如下。
1 using System.Collections;
2 using System.Collections.Generic;
3 using NUnit.Framework;
4 using UnityEngine;
5
6 public class PlayerTest{
7
8 [Test]
9 public void TestHealth()
10 {
11 Player player = new Player();
12 player.Health = 1000.0f;
13
14 //通过Assert断言来判断这个函数的返回结果是否符合预期
15 player.Damage(200);
16 Assert.AreEqual(800,player.Health);
17
18 player.Recover(150);
19 Assert.AreEqual(950,player.Health);
20 }
21
22 [Test]
23 [ExpectedException(typeof(NegativeHealthException))]
24 public void NegativeHealth()
25 {
26 Player player = new Player();
27 player.Health = 1000;
28
29 player.Damage(500);
30 player.Damage(600);
31 }
32
33 }
相信大家在写到 [ExpectedException(typeof(NegativeHealthException))] 的时候，VS肯定会报红，提示找不到 ExpectedException 这个标签，这是因为，ExpectedException这个标签是属于VS的单元测试的内容，在 NUnit.Framework 这个命名空间中，因此我们还需要使用 using NUnit.Framework; 来引入VS的单元测试模块。但是如果你会发现这个模块无法引入，VS没有自动补全这个命名空间，就算手动写上了还是提示找不到。这是为什么呢？
众所周知，Unity的.NET是基于 Mono 的，因为一些原因，导致Mono并不是包含了所有微软原生的.NET库中的内容。也就是说有些你在Winform、WPF等工程中用到的类库并不能完美地在Mono中使用，这也就是为什么会发生上述找不到单元测试的模块的问题。其实这个问题也很好解决，我们只要把 VS 中的单元测试模块的DLL找到（名为 Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll ），手动拷贝到Unity工程中，再在IDE里面引入它就可以使用了。具体的操作步骤如下：
1.找到VS中的单元测试模块DLL的所在位置，经过在 Stackoverflow 上面查询，我们得知Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll 一般在 C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll 路径下。如下图所示：
2.把这个DLL手动拷贝到Unity的工程中，并在我们的解决方案中引用它。在我们的Unity项目中新建一个名为 “Plugins” 的文件夹，然后把上面的Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll 拷贝到该文件夹下，再重新打开我们的VS解决方案，就可以发现，这个模块已经自动被引用进来了，之后就可以放心地使用单元测试相关的代码了。
一般在传统的C#项目中，我们引用某个DLL的时候，都是通过在VS解决方案的引用项目上右键 -> 添加新引用来导入某个DLL，但是在Unity的项目中，我们在引用选项上右键却发现没有这个选项。其实，只要像上述的那样直接把dll 拷贝到 "Plugins"目录下，VS就会自动把DLL引用到我们的项目中了，非常方便。
在上面的测试函数中，假如我们想测试Damage这个函数是否正常工作，需要使用 Assert.AreEqual 来判断这个函数的返回结果是否与预期的结果一致。如果Assert.AreEqual判断结果是正确的，就会在Tests Runner窗口中用一个绿色的对号表示这个测试通过了，反之就会用红色的禁止符号表示失败。第二个名为 NegativeHealth 测试用例函数，是用来判断判断这个函数有没有正常地抛出异常，如果没有按照预期抛出异常也会被认为是失败的测试用例。如果你需要捕获抛出异常与你的预期值是否一致，还需要在函数前添加另外一个属性 [ExpectedException(typeof(NegativeHealthException))]，这样这段代码就会判断抛出的异常是否正确了。通过下图可以看到，我们所编写的两个测试函数用例都通过了，显示为绿色。
这时候大家可能发现了，上面的脚本对应了测试结果中PlayerTest这一部分，另外还有一个PlayerTestWrong的分组并没有出现。这是因为我们可以在Editor目录下添加多个测试脚本，这些测试脚本可以测试同一个模块的代码，也可以同时测试不同模块的代码。下面让我们来看一下PlayerTestWrong的脚本如何编写，它的内容和刚才的测试代码非常相似，只不过调用了返回错误值的函数。
1 using System;
2 using System.Collections.Generic;
3 using System.Linq;
4 using System.Text;
5 using NUnit.Framework;
6
7
8 class PlayerTestWrong
9 {
10 [Test]
11 public void TestHealthWrong()
12 {
13 Player player = new Player();
14 player.Health = 1000.0f;
15
16 player.DamageWrong(200);
17 Assert.AreEqual(800,player.Health);
18
19 player.DamageWrong(150);
20 Assert.AreEqual(950,player.Health);
21 }
22
23 [Test]
24 [ExpectedException(typeof (NegativeHealthException))]
25 public void NegativeHealthNoException()
26 {
27 Player player = new Player();
28 player.Health = 1000;
29
30 player.DamageNoException(500);
31 player.DamageNoException(600);
32 }
33 }
Editor Tests Runner的基本使用方法介绍到这里就结束了，下面介绍一个小技巧。如果你想实现全自动的单元测试的话，可能会考虑使用批处理来自动化执行测试，为此Unity也提供了批处理的方式。如果你需要使用这个功能的话，只需要在运行Unity的时候传入以下参数，每个参数的含义请查看 Unity官方文档 ，本篇博客中就不进行介绍了。
- runEditorTests
- editorTestsResultFile
- editorTestsFilter
- editorTestsCategories
- editorTestsVerboseLog
三、小结
对于游戏开发者来说，单元测试可能比较陌生。不过现在随着游戏复杂度的逐渐提升，另外很多有一定规模的公司都会同时开发多个项目。我们会发现其实有很多功能都被封装为通用的工具库。在这种情况下如果我们再不重视代码的质量，就会导致一个Bug可能同时影响多个项目的开发进度。因此我们还是建议在时间允许的情况下，对比较重要的模块，以及重用性比较高的代码增加单元测试。
最后放上本篇博客中演示的项目源码：
Github地址：https://github.com/XINCGer/Unity3DTraining/tree/master/Unit4Unity/Editor%20Test%20Runner 欢迎fork！
引用资料：
作者：马三小伙儿
出处：http://www.cnblogs.com/msxh/p/7354229.html
请尊重别人的劳动成果，让分享成为一种美德，欢迎转载。另外，文章在表述和代码方面如有不妥之处，欢迎批评指正。留下你的脚印，欢迎评论！