【译】UNITY断言库使用指南

原文地址：http://blogs.unity3d.com/2015/08/25/the-unity-assertion-library/

原文作者未做版权声明，视为共享知识产权进入公共领域，自动获得授权

Unity5.1包含了一个全新的断言库。在这篇文章里面，我们将解释什么是断言以及你怎么用它来改善游戏运行时错误的诊断。

断言是什么以及为什么需要它  

断言是一个条件检 测方法。如果条件为真，方法会返回，执行也会继续。如果一些意想不到的事情发生导致假设条件不满足，将输出一条显示调用堆栈的消息，是否输出用户自定义信息是可选的。让我们看一个例子:

//Make sure theplayer GameObject is active

Assert.IsTrue(playerGameObject.isActive,“Player GameObject is not active”);

如果引用的GameObject不在激活状态，一条错误信息将会打印出来，显示调用堆栈和自定义信息“Player GameObject is not active”。

许多开发人员是从单元测试知道断言的。在使用Arrange-Act-Assert模式编写的单元测试，这是测试方法的最后一步，在这一步里你会比较预期和实际的结果。不过断言不只是为测试。你也可以在工程代码里面使用断言，这样在运行的时候，如果变量出现问题，就会得到警告。但是不是所有的断言都应该被用在运行时代码。

为什么从单元测试框架中提出断言库？

可能你第一次遇到断言是在单元测试框架里面。作为例子，让我们看下NUnit。NUnit对于断言测试有着丰富地经过测试的库。很自然地会引出一个问题，为什么不直接用这个库测试工程代码？这有几个原因，一个简单的答案是：它不是为这个目的设计的。

NUnit允许你对很多东西进行断言。从简单的相等比较到更复杂的集合测试。这些东西都很好，但是它会导致运行变慢。底层断言需要尽可能的简单以及减少不必须要的开销。断言库没有额外的内存分配和不必要的操作

.

对断言库来说一个比较重要的事情是从发布版本中移除断言的部分，在开发阶段断言对于开发人员是非常重要的，但是对于最终用户来说是不需要的。当构建最终版本的时候，你希望能不打入这些断言。你可以一行行注释掉这些断言，但是这个方法太笨了。幸运的是.NET有一个条件编译机制来面对这种情况。断言库实现了条件属性，这样它只会包含在开发版本里面。当然通过编译选项，你还是可以强制最终版本里有断言。

最后但并非最不重要的，单元测试的断言一半是基于异常的。异常是在执行出现问题的时候抛出一个错误。很明显，这不是运行时代码所希望。断言库已经和Unity日志系统集成，当失败的时候，一条信息会被记录。它使得断言库在所有平台上都表现一致。这也意味着断言库可以在不支持异常的AOT平台上运行。

库都包括了什么？

库提供了几个特定类型的比较方法和一个通用的判断相等的比较器。一些带断言的方法

• AreEqual –用于判断相等的通用比较器，使用默认的等于方法。
• AreApproximatelyEqual –能容忍误差的近似比较器。可用于比较浮点数。
• IsTrue –用于快速简单的布尔类型检测。

所有方法都可在 Assertdocumentation找到。

扩展库

当你想充分使用一个功能的时候，一个很自然的想法就是扩展它，库的AreEqual方法允许你传入自己视线的比较方法。比较器必须实现必须实现IEqualityComparer接口。库有FloatComparer用于浮点数比较。它允许你设定一个误差来做比较。这个比较器被用于AreApproximatellyEqual方法。

总结

使用断言库来保护代码不受bug和非预期状态的影响是简单并可马上使用的，这个库会随着时间变得更好，并且和以往一样，非常欢迎你的评论和建议！