使用断言的最佳时机偶尔会被提起，通常是因为有人误用，因此我觉得有必要写一篇文章来阐述一下什么时候应该用断言，为什么应该用，什么时候不该用。
对那些没有意识到用断言的最佳时机的人来说，Python的断言就是检测一个条件，如果条件为真，它什么都不做；反之它触发一个带可选错误信息的AssertionError。如下例所示：
很多人将断言作为当传递了错误的参数值时的一种快速而简便的触发异常的方式。但实际上这是错误的，而且是非常危险的错误，原因有两点。首先，AssertionError通常是在测试函数参数时给出的错误。你不会像下面这样编码：
你应该用TypeError来替代，“断言”解决了错误的异常类型。
但是对断言来说更危险也更纠结的是：如果你执行Python时使用了-O或-OO优化标识，这能够通过编译却从来不会被执行，实际上就是说并不能保证断言会被执行。当恰当地使用了断言，这非常好的，但当不恰当地使用了断言，在使用-O标识执行时它将导致代码被彻底中断。
那么我们什么时候应该使用断言呢？如果没有特别的目的，断言应该用于如下情况：
- 防御性的编程
- 运行时对程序逻辑的检测
- 合约性检查（比如前置条件，后置条件）
- 程序中的常量
- 检查文档
（断言也可以用于代码测试，用作一个做事毛手毛脚的开发人员的单元测试，只要能你接受当使用-O标志时这个测试什么都不做。我有时也会在代码中用"assert Fasle"来对还没有实现的分支作标记，当然我希望他们失败。如果稍微更细节一些，或许触发NotImplementedError是更好的选择）
因为程序员是对于代码正确性表现出的信心不同，因此对于什么时候使用断言的意见各不相同。如果你确信代码是正确的，那么断言没有任何意义，因为它们从不会失败，因此你可以放心地移除它们。如果你确信它们会失败（例如对用户输入的数据的检测），你不敢用断言，这样编译就能通过，但你跳过了你的检查。
在以上两种情况之间的情况就显得特别有趣了，那就是当你相信代码是正确的，但又不是特别确定的时候。或许你忘记了一些奇怪的边角情况（因为我们都是人），在这种情况下，额外的运行时检查将帮助你尽可能早地捕获错误，而不是写了一大堆代码之后。
（这就是为什么使用断言的时机会不同。因为我们对代码正确性的信息不同，对于一个人有用的断言，对于另一个人来说却是无用的运行时测试。）
另一个断言用得好的地方就是检查程序中的不变量。一个不变量是一些你能相信为真的条件，除非一个缺陷导致它变成假。如果有一个缺陷，越早发现越好，因此我们需要对其进行测试，但我们不想因为这些测试而影响代码执行速度。因此采用断言，它能在开发时生效而在产品中失效。
一个关于不变量的例子可能是这样的情况。如果你的函数在开始的时候期望一个打开的数据库连接，并且在函数返回后该数据库连接依然是打开的，这是一个函数的不变量：
断言也是一个很好的检查点注释。为了替代如下注释：
#当我们执行到这里，我们知道n>2
你可以确保在运行时用以下断言：
断言也是一种防御性的编程形式。你不是在防范当前代码发生错误，而防范由于以后的代码变更发生错误。理想情况下，单元测试应该直到这个作用，但是让我们面对这样一个现实：即使存在单元测试，他们在通常情况下也不是很完备。内建的机器人可能没有工作，但数周以来也没有人注意到它，或者人们在提交代码之前忘记了执行测试。内部检查将是防止错误渗入的另一道防线，尤其对于那些悄悄地失败，但会引起代码功能错误并返回错误结果的情况有效。
假设你有一系列的if...elif代码块，你预先知道变量期望的值：
假设这段代码现在完全正确。但它会一直正确吗？需求变更，代码变更。如果需求变为允许target = w，并关联到run_w_code，那将会发生什么情况？如果我们变更了设置target的代码，但是忘记了改变这个代码块，它就会错误地调用run_z_code()，错误就会发生。对于这段代码最好的方法就是编写一些防御性的检查，这样它的执行，即使在变更以后，要么正确，要么马上失败。
在代码开始添加注释是个好的开端，但是人们都不太喜欢读和更新这些注释，这些注释会很快变得过时。但对于断言，我们可以同时对这块代码编写文档，如果这些断言被违反了，会直接引起一个简单而又直接的失败。
这里的断言同时用于防御性编程和检查文档。我认为这是最优的解决方案：
这诱使开发者去不理代码，移除像value ==c这类不必要的测试，以及RuntimeError的“死代码”。另外，当"unexpected error"错误发生时这个消息将非常窘迫，确实会发生。
合约式设计是断言另一个用得好的地方。在合约式设计中，我们认为函数与其他调用者遵循合约，例如像这样的情况：
“如果你传给我一个非空字符串，我保证返回转换成大写的首字母。”
如果合约被破坏了，不管是被函数本身还是调用者，这都会产生缺陷。我们说这个函数需要有前置条件（对期望的参数的限制）和后置条件（对返回结果的约束）。因此这个函数可能是这样的：
合约式设计的目的是，在一个正确的程序里，所有的前置条件和后置条件都将得到处理。这是断言的经典应用，自（这个想法持续）我们发布无缺陷的程序并且将其放入产品，程序将是正确的并且我们可以放心地移除检查。
这里是我建议不使用断言的情况：
*不要用于测试用户提供的数据，或者那些需要在所有情况下需要改变检查的地方
*不要用于检查你认为在通常使用中可能失败的地方。断言用于非常特别的失败条件。你的用户绝不看到一个AssertionError，如果看到了，那就是个必须修复的缺陷。
*特别地不要因为断言只是比一个明确的测试加一个触发异常矮小而使用它。断言不是懒惰的代码编写者的捷径。
*不要将断言用于公共函数库输入参数的检查，因为你不能控制调用者，并且不能保证它不破坏函数的合约。
*不要将断言用于你期望修改的任何错误。换句话，你没有任何理由在产品代码捕获一个AssertionError异常。
*不要太多使用断言，它们使代码变得晦涩难懂。