利用编辑器测试工具检查Unity脚本文档

如果遇到不熟悉的API，第一反应肯定是查看Unity文档，通过文档示例来了解API使用方式。但如果按照文档示例却编译失败，那有没有可能是文档出错了呢？

Unity Hackweek的其中一个项目，就是利用Unity 5.3及以上版本的编辑器测试工具，来自动检验所有Unity脚本文档的示例代码是否编译成功。

Unity脚本文档共有15000页左右，其中并非所有文档都包含示例（这需要另外解决），但包含示例的也不在少数。手动查看每个文档并进行测试在为期一周的Hackweek中是很难实现的，也无法解决未来的API更改导致的更新问题。

去年发布的Unity 5.3中包含一个新功能：Editor Test Runner，它是能在Unity中运行的单元测试框架。自该功能发布后就一直用于Unity内部测试，帮助我们追踪问题。Unity所有脚本文档都保存为XML文件，可以在Unity内部项目中进行编辑。

项目已经包含解析XML文件的代码，所以只需在项目中加上编辑器测试即可重用这些功能。在编辑器测试框架中会用到TestCaseSource属性，让测试多次在不同的源数据上运行。在本例中，源数据就是脚本案例文档：

该方法展示了所有运行在Test Runner上的测试。每个测试都能独立运行，或通过Run ALL选项来同时运行。

本例使用CodeDomProvider 编译，这样可以传递多个表示脚本的字符串，并编译和返回相关的错误及警告信息。

首次测试迭代的缩减版（已删除XML解析）：

编译脚本的方式还需做些调整，因为有些脚本可能组合在一起形成一个示例。分别编译所有示例以检测是否有这种情况，如果出现错误再将其合并编译，看看是否成功。

还有一些简单示例就是一行代码，没有封装在函数内。可以在测试中进行封装来修复这个问题，要遵循的规则就是这些例子必须能独立运行（即用户将其复制粘贴到一个新的文件中，也可以被编译和运行），否则就将这些示例视为测试失败。

该测试现在离正式作为文档验证工具并合并到主分支还有一段距离。还需解决一个小：测试运行需花费30分钟·。由于每天运行约7000个版本，仅作为一个版本验证测试来说这个运行时间太长了。

目前该测试是顺序进行的，一次一个脚本。由于测试彼此独立，且无需调用Unity API，因为仅测试编译是否成功，所以完全可以并行运行这些测试。下面引入用于并行执行任务的.NET API-线程池。将测试作为单个任务放入线程池中，当线程可用时立即执行。这需要从单个函数执行，即不能用单独的NUnit测试用例来测试文档的单一示例。尽管不能单独测试，但我们大大提高了整体运行的速度。

这将测试时间从30分钟缩短至2分钟，作为版本验证来说已满足需求。由于无法测试单个示例，所以在脚本文档编辑器中加入按钮，以便文档编写人员日后更新。运行测试时出错脚本会显示为红色，并在下方显示出错信息。

首次运行测试时有326个错误，将其加入白名单以便日后更新。现在已减少为32个，大多错误都是由于无法访问特定的程序集导致。集成该测试并未引入新的问题，所以可以确定如果弃用部分API导致测试失败，则需要更新文档来使用新的API。

结语

本文只是Editor Test Runner工具一个非常有趣的使用案例，该示例也有些缺点，例如只能获取C#示例，无法处理.js的编译。但在不久的将来，这也将不再是问题。我们还会为大家分享一些Unity内部有趣而实用的案例在Unity官方中文社区（unitychina.cn），请保持关注。

请点击【阅读原文】查看完整的测试代码。

推荐阅读

点击“阅读原文”进入Unity官方中文社区！