在IBM DeveloperWorks里看到的，顺便记录下来。
编写哪些测试以及如何编写这些测试:
- 所有正面测试
- 这组测试可以确保所有的东西都如我们期望的一样工作。
- 所有负面测试
- 逐一使用这些测试，从而确保每个失效或异常情况都被测试到了。
- 正面序列测试
- 这组测试可以确保按照正确顺序的调用可以像我们期望的一样工作。
- 负面序列测试
- 这组测试可以确保当不按正确顺序进行调用时就会失败。
- 负载测试
- 在适当情况下，可以执行一小组测试来确定这些测试的性能在我们期望的范围之内。例如，2,000 次调用应该在 2 秒之内完成。
- 资源测试
- 这些测试确保应用编程接口（API）可以正确地分配并释放资源 —— 例如，连续几次调用打开、写入以及关闭基于文件的 API，从而确保没有文件依然是被打开的。
- 回调测试
- 对于具有回调方法的 API 来说，这些测试可以确保如果没有定义回调函数，代码可以正常运行。另外，这些测试还可以确保在定义了回调函数但是这些回调函数操作有误或产生异常时，代码依然可以正常运行。
这是有关单元测试的几点想法。有关如何编写单元测试，我也有几点建议：
- 不要使用随机数据
- 尽管在一个界面中产生随机数据看起来貌似一个好主意，但是我们要避免这样做，因为这些数据会变得非常难以调试。如果数据是在每次调用时随机生成的，那么就可能产生一次测试时出现了错误而另外一次测试却没有出现错误的情况。如果测试需要随机数据，可以在一个文件中生成这些数据，然后每次运行时都使用这个文件。采用这种方法，我们就获得了一些 “噪音” 数据，但是仍然可以对错误进行调试。
- 分组测试
- 我们很容易累积起数千个测试，需要几个小时才能执行完。这没什么问题，但是对这些测试进行分组使我们可以快速运行某组测试并对主要关注的问题进行检查，然后晚上运行完整的测试。
- 编写稳健的 API 和稳健的测试
- 编写 API 和测试时要注意它们不能在增加新功能或修改现有功能时很容易就会崩溃，这一点非常重要。这里没有通用的绝招，但是有一条准则是那些 “振荡的” 测试（一会儿失败，一会儿成功，反复不停的测试）应该很快地丢弃。