今年Unite上的Unity Editor新功能讲座中介绍了三个工具,前两个介绍的是Frame Debugger和新的Memory Profiler。今天要介绍的Editor Tests Runner是三个工具中的最后一个。

Editor Tests Runner是开源单元测试工具NUnit在Unity引擎中的实现,目前Unity中使用的NUnit版本是2.6.4。如果你想了解更多NUnit的内容,请访问这个链接http://www.nunit.org/index.php?p=quickStart&r=2.6.4
单元测试在传统软件开发中是非常重要的工具,它是指对软件中的最小可测试单元进行检查和验证,一般情况下就是对代码中的一个函数去进行验证,检查它的正确性。
对一直从事游戏开发的人来说,Unit Test可能比较陌生。不过现在随着游戏复杂度的逐渐提升,另外很多有一定规模的公司都会同时开发多个项目。我们会发现其实有很多功能都被封装为通用的工具库。在这种情况下如果我们再不重视代码的质量,就会导致一个bug可能同时影响多个项目的开发进度。因此我们还是建议在时间允许的情况下,对比较重要的模块,以及重用性比较高的代码增加单元测试。
下面我们介绍一下这个工具的使用,Editor Tests Runner可以通过Window -> Editor Tests Runner菜单打开,下面是这个工具窗口的截图。

在这个窗口中显示了当前添加的单元测试用例,以及他们通过的情况。首先,你需要点击窗口左上角的Run All按钮来执行所有的单元测试。绿色的对号表示这个用例通过了单元测试,红色的禁止符号表示未通过单元测试。
下面我们来看一下如何编写单元测试的代码。单元测试代码和游戏运行时代码是分开保存的,它只在Editor环境下可用,因此你需要把它放到Editor目录下。首先我们假设游戏代码中存在一个Player类来代表主角色,里面有几个函数用来在玩家受到伤害时减少血量,或者通过药水回复血量,下面的截图是游戏运行时代码。其中Damage函数写了三个版本,一个是正确的,两个是返回错误结果的。

下面我们需要写单元测试代码了。这里我们创建了一个叫做PlayerTest的类,里面写了两个函数分别代表两个测试用例。为了让Unity识别这两个函数是测试用例,我们需要在函数前加上[Test]的属性,这样所有带有[Test]属性的函数都会成为一个测试用例。

在测试函数中,假如我们想测试Damage这个函数是否正常工作,需要使用Assert.AreEqual来判断这个函数的返回结果。如果Assert.AreEqual判断结果是正确的,就会在Tests Runner窗口中用一个绿色的对号表示这个测试通过了,反之就会用红色的禁止符号表示失败。
这时候大家可能发现了,上面的脚本对应了测试结果中PlayerTest这一部分,另外还有一个PlayerTestWrong的分组并没有出现。这是因为我们可以在Editor目录下添加多个测试脚本,这些测试脚本可以测试同一个运行时代码文件,或者分别测试不同的运行时代码。

除了PlayerTest测试代码以外,我们还添加了另外一个PlayerTestWrong测试代码。

它的内容和刚才的测试代码非常相似,只不过调用了返回错误值的函数。另外这里还有一个测试用例判断这个函数有没有正常的抛出例外,如果没有按照预期抛出例外也会被认为是失败的测试用例。这是通过在函数前添加另外一个属性来实现的,[ExpectedException(typeof(NegativeHealthException))]。当然不要忘记在代码中添加这个例外的定义。

Editor Tests Runner的基本使用方法介绍到这里就结束了,下面介绍一个小技巧。如果你想实现全自动的单元测试的话,可能会考虑使用批处理来自动化执行测试,为此Unity也提供了批处理的方式。如果你需要使用这个功能的话,只需要在运行Unity的时候传入以下参数,每个参数的含义请查看Unity官方文档。

  • runEditorTests
  • editorTestsResultFile
  • editorTestsFilter
  • editorTestsCategories
  • editorTestsVerboseLog

下面是一个命令行执行的示例,通过Editor退出时返回的结果你可以知道测试有没有通过。0代表全部运行成功,2代表运行成功但是测试结果有错,3代表由于其他原因运行失败。

以上是本篇介绍的全部内容,希望对大家有所帮助。

来源:unity官方平台