测试综述

单元测试

常常将测试代码和运行代码一起写是一种非常好的习惯。

测试的通用规则

1. 测试单元应该集中于小部分的功能，并且证明它是对的。
2. 每个测试单元必须完全独立。他们都能够单独运行，也可以在测试套件中运行，而不用考虑被调用的顺序。 要想实现这个规则，测试单元应该加载最新的数据集，之后再做一些清理。 这通常用方法 setUp() 和 tearDown() 处理。
3. 尽量使测试单元快速运行。把运行吃力的测试单元放在单独的测试组件中， 并且按照需要运行其它测试单元。
4. 学习使用工具，学习如何运行一个单独的测试用例。然后，当在一个模块中开发了一个功能时， 经常运行这个功能的测试用例，理想情况下，一切都将自动。
5. 在编码会话前后，要常常运行完整的测试组件。
6. 实现钩子（hook）是一个非常好的主意。因为一旦把代码放入分享仓库中， 这个钩子可以运行所有的测试单元。
7. 如果您在开发期间不得不打断自己的工作，写一个被打断的单元测试，它关于下一步要开发的东西。 当回到工作时，您将更快地回到原先被打断的地方，并且步入正轨。
8. 当您调试代码的时候，首先需要写一个精确定位bug的测试单元。尽管这样做很难， 但是捕捉bug的单元测试在项目中很重要。
9. 测试函数使用长且描述性的名字。 当测试单元失败时，函数名应该显示，而且尽可能具有描述性。
10. 当发生了一些问题，或者不得不改变时，如果代码中有一套不错的测试单元， 维护将很大一部分依靠测试组件解决问题，或者修改确定的行为。因此测试代码应该尽可能多读， 甚至多于运行代码。目的不明确的测试单元在这种情况下没有多少用处。
11. 测试代码的另外一个用处是作为新开发人员的入门介绍。当有人需要基于现有的代码库工作时， 运行并且阅读相关的测试代码是最好的做法。他们会或者应该发现大多数困难出现的热点，以及边界的情况。 如果他们必须添加一些功能，第一步应该是添加一个测试，以确保新的功能不是一个尚未插入到界面的工作路径。

单元测试

unittest 模块

文档测试

doctest: 查找零碎文本，就像在Python中docstrings内的交互式会话，执行那些会话以证实工作正常。

工具

• py.test: 要比单元测试模型中相同功能所要求的工作量少得多。
• Hypothesis: 让您编写被示例源码参数化的测试的库。它会生成简单易懂的例子，使您的测试失败， 让您花更少的力气找到更多的错误。
• tox: 自动化测试管理和针对多种解释器配置测试工具
• mock: 在测试环境下，使用mock对象能够替换部分系统，并且对它们如何被使用做了声明