--Stay hungry, stay foolish.
--Forever young, forever weep.
在写技术模块的规格说明书（Specification）的时候，要越详细越好，最好各项要求都可以表示为一个单元测试用例。如果不能表示为一个单元测试用例，只能说明写的不够细。
如果你写的模块会有不同的人在不同的时间使用，那你最好把这一“单元”要做的事，以及它不能做的事，用单元测试清晰地表达出来。同时单元测试也能帮助程序员记录这个模块的历史和设计变更的理由。
单元测试应该正确、快速地保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准：
单元测试应该在最低的功能/参数上验证程序的正确性：单元测试应该测试程序中最基本的单元，如在C++/C#/Java中的类，在此基础上可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成）。从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每个方法及每个参数。
单元测试必须由最熟悉代码的人来写：如果忙到连单元测试都没有时间做，那么你也没有时间写好对应的功能。在一些极限编程中，是可以考虑让别人来做单元测试的，但是，程序的作者还是要对单元测试负责。
最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义。
单元测试过后，机器状态保持不变：无论是修改过文件、文件夹还是数据库，都应该将它们恢复到测试之前的状态。
单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）
单元测试应该产生可重复的、一致的结果：如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可重复的。
我们还是要用随机数等办法“增加测试的真实性”，但不是在单元测试中。单元测试不能解决所有问题，不必期望它会发现所有的缺陷。
独立性——单元测试的运行/通过/失败不能依赖于别的测试，可以认为构造数据，以保持单元测试的独立性。
测试代码应该覆盖所有代码路径：单元测试应覆盖所测单元的所有代码路径，为了保证代码覆盖率，单元测试必须测试公开的和私有的函数/方法。
单元测试应该集成到自动测试的框架中：要把单元测试自动化，这样每个人都能随时、随地运行单元测试。团队一般是在每日构建之后运行单元测试的，这样单元测试的错误就能及时发现并得到修改。
单元测试必须和产品代码一起保存和维护。
在修改了代码之后，重新测试以前已经测试过的代码，这个过程最好是实现自动化。