2.3.2　断言的时机

到底什么时候使用断言比较好呢？可以从开发和测试两个方面为大家简单介绍断言的时机及不使用断言的情况。

开发人员　通常在下面时机点添加断言（本书以测试为主，对开发只做简单介绍）：

• 防御性地编程，也就是不满足条件时直接显示失败。示例代码如下：

上述代码，当target为x时运行run_x_code（）;当target为y时运行run_y_code（）;当target为其他情况时运行else中的代码，也就是target如果为z，则运行run_z_code（）;如果不是上述内容，会直接引起一个简单而又直接的失败。

• 运行时对程序逻辑检测；
• 合约性检查（例如前置条件、后置条件）；

例如：“如果你传给笔者一个非空字符串，笔者保证返回首字母转换成大写的字符串。”

• 程序中的常量；
• 检查文档。

测试人员　通常对所有需要比对的需求及功能进行验证时使用断言，下面分析一下断言的主要时机点：

• 验证页面是否跳转到正确的页面；
• 验证计算结果与正确结果是否一致；
• 验证类型是否一致；
• 验证添加功能是否成功添加；
• 验证接口返回的JSON数据是否正确；
• 验证接口返回的状态码是否正确；
• 验证接口性能是否在范围内；
• 验证元素是否已被选择；
• 验证元素是否为不可操作；
• 验证返回值是否与预期一致。

不使用断言的几种情况：

• 不要用于测试用户提供的数据，或者那些在所有情况下需要改变检查的地方；
• 不要用于检查你认为在通常使用中可能失败的地方；
• 用户绝看不到一个AssertionError，如果看到了，那就是必须修复的缺陷；
• 特别地不要因为断言只比一个明确的测试加一个触发异常简单而使用它。断言不是懒惰的代码编写者的捷径；
• 不要将断言用于公共函数库输入参数的检查，因为用户不能控制调用者，并且不能保证它不破坏函数的执行；
• 不要将断言用于用户期望修改的任何地方。换句话，用户没有任何理由在产品代码中捕获一个AssertionError异常；
• 不要太多使用断言，它们将使代码变得晦涩难懂。