单元测试代码的要求
- 测试应与生产代码应在同一个时间段内编写，先写测试代码再写生产代码。每编玩一个新的功能，就应该写测试来检验功能的是否实现。每次更改生产代码，也应修改测试代码。
- 保持测试代码的整洁。不要以为只是测试就不写整洁的代码，脏测试等同于没测试。测试必须随生产代码的眼镜儿修改，测试代码越脏，就越难修改，修改生产代码后，测试就会开始失败，随着版本的演进，团队维护测试代码的代价也在上升，而随着开发的进行，开发压力的一直增大，最终会导致开发者扔掉整个测试站组。一旦没了测试代码，程序员就失去了确保对代码的改动能如愿工作的能力。这时候整个生产代码开始腐坏。
编写单元测试的技巧
- 每个测试一个断言。每个测试中的断言，要尽可能少！不能把不同的测试放在一起。
- 我们通过打造一套包装这些api的函数和工具代码，这样就可以更方便的编写测试，写出来的测试，也更便于阅读。我们通过测试那些函数和工具代码，从而测试那些api。
- 函数和工具代码也以功能为构建目标，不同的功能用不同的函数。
- 这种测试的函数和代码工具并非当初就设计出来，而是在对那些充满令人迷惑细节的测试代码进行后续重构时逐渐演进。
测试带来的好处
单元测试让你的代码可扩展，可维护，可复用。没有测试，每次修改都可能带来缺陷。
编写单元测试的模式
单元测试可以采取构造-操作-检验模式写成一个函数。也就是将测试拆分为三个环节，第一个环节构造测试数据，第二个环节操作测试数据的，三个环节，检验操作是否得到期望的结果。
测试代码与生产代码的不同
- 测试代码应当简单精悍足具表达力。有些事你大概永远不会在生产环境中做，而在测试环境中做却完全没问题。 通常这关乎内存和upu效率的问题(比方要求在多少秒内，内存不应该超过多少多少)。
- 这是代码应该极具阅读性。
整洁的测试遵循的规则
- 快速。测试不应该过于缓慢，如果测试过于缓慢，你就会不想频繁的测试，如果你不频繁运行测试，就不能尽早发现问题。代码将腐化。
- 独立。测试之间应该相互独立，一个功能一个功能的测试，不会相互依赖。
- 可重复。测试应当可在任何反应中重复通过。
- 自足验证。测试的结果应该明显，最好是bool值，不应通过查看日志这种低效率的方法来判断测试是否通过。应当由程序来判断。
- 及时。测试应该及时编写。单元测试，应该恰好在使其通过的生产代码之前编写。
