单元测试的作用：让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证

1. 单元测试应该在最基本的功能/参数上验证程序的正确性 

单元测试应该测试程序中最基本的单元—如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成）。从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法及每一个参数

2. 单元测试必须由最熟悉代码的人（程序的作者）来写 

代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义

3. 单元测试过后，机器状态保持不变 

这样就可以不断地运行单元测试，如果单元测试创建了临时的文件或目录，应该在Teardown阶段删掉。如果单元测试在数据库中创建或修改了记录，那么也许要删除或恢复这些记录，或者每一个单元测试使用一个新的数据库，这样可以保证单元测试不受以前单元测试实例的干扰

4. 单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟） 

快，才能保证效率。因为一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中可以分类，如数据库层次、网络通信层次、客户逻辑层次和用户界面层次，可以分类运行测试，比如只修改了“用户界面”的代码，则只需运行“用户界面”的单元测试

5. 单元测试应该产生可重复、一致的结果 

如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的，单元测试不能解决所有问题，不必期望它会发现所有的缺陷

6. 独立性—单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性 

程序中的各个模块都是互相依赖的，否则它们就不会出现在一个程序中。一般情况下，单元测试中的模块可以直接引用其他的模块，并期待其他的模块能返回正确的结果。如果其他的模块很不稳定，或者其他模块运行比较费时（如进行网络操作），而且对于本模块的正确性并不起关键的作用，这时可以人为地构造数据，以保证单元测试的独立性

7. 单元测试应该覆盖所有代码路径 

单元测试应覆盖所测单元的所有代码路径，包括错误处理路径。为了保证代码覆盖率，单元测试必须测试公开的和私有的函数/方法 

100%的代码覆盖率并不等同于100%的正确性！

• 代码覆盖率对于“应该写但是没有写的代码”无能为力。例如代码申请了内存或其他资源，但并没有释放。又如，代码中并没有处理错误情况。就像没有处理和文件、网络相关的一些异常情况，例如文件不存在、权限有问题，等等

• 代码中有效能问题，虽然代码执行了，并且也正确地返回了，但是代码效率非常低。有些情况下，可以针对代码效率写一个单元测试

• 多线程环境中的同步问题，这个问题和代码执行的时序、共享资源的锁定有关

• 其他与外部条件相关的问题（例如与设备、网络相关的问题）

8. 单元测试应该集成到自动测试的框架中 

要把单元测试自动化，这样每个人都能随时、随地运行单元测试。团队一般是在每日构建之后运行单元测试的，这样单元测试的错误就能及时被发现并得到修改

9. 单元测试必须和产品代码一起保存和维护 

单元测试必须和代码一起进行版本维护。如果不是这样，过了一阵，代码和单元测试就会出现不一致，程序员要花时间来确认哪些是程序出现的错误，哪些是由于单元测试滞后造成的错误