1单元的定义

单元是指完成单一（较小）功能的相关数据（数据结构）及对应算法函数集的集合。

功能块的划分并没有标准可依，只要代码行数还比较多，就都可以把一个功能块再拆分为若干子功能块。一般代码量在200～2000行的，可以认为是单元；超过2000行的可以认为是模块，需要进行功能块拆分；小于200行的，应该进行功能块聚合。

单元应该只含有单一逻辑。通过收发消息进行耦合的代码，由于同时含有业务逻辑（业务流程）和并发逻辑（操作系统层面的收发消息、信号量、定时器等），一般都划为模块。将2种逻辑解耦后，只含业务逻辑的代码才考虑是否可以简单到成为单元

SDL进程状态机一般都逻辑略嫌复杂，应该划为模块，它的每个进程页才考虑是否可以简单到成为单元。

一个大功能块拆分为多个子功能块时，必然还有大量代码不能划入任何一个子功能块，这些代码则是集成测试时所要关注的内容。单元测试阶段并不要求所有代码都经测试覆盖。

没有返回值、回传参数，也不向外发送消息的函数不可能独立构成单元。

2单元测试的重点

单元测试时关注的核心是数据而不是算法函数。因为功能的完成总是以数据发生变化来表现的。

3单元测试的目的

l        单元测试能发现很多设计、编码中的错误。但是，要发现几乎所有错误，它的工作量将是非常大的。由于单元测试是由开发人员完成的，这样做将会严重影响开发进度。所以，“发现几乎所有错误”的责任在软件工程里一直都是交由独立的测试部门完成的。所以，单元测试不该对黑白盒覆盖率提太高的指标，一般都是用例制。

l        单元测试用来证明代码满足“客户需求”。单元测试的用例应该模拟客户使用这些代码的方式。当单元测试通过的时候，我们就能知道客户的需求被满足了；当我们不知道如何写单元测试代码时，就意味着客户也将不知道如何使用这些单元代码。

l        单元测试用来证明bug已经被修复。当发现bug时，应该先拟制一个新的单元测试用例，它能确保触发bug，修改bug后，再跑这个测试用例，当成功通过过，我们就可以认为bug确实被修复了。

l        单元测试能确保后来对代码的修改没有破坏已有功能。无论修改bug还是追增功能，都很容易导致已有功能被破坏。如果能用自动测试机对已有测试用例自动跑一遍，就可以确保已有功能未遭破坏。

4单元测试的投入

           代码走查、单元测试、模块测试……都可以提高软件质量。但是，软件开发是一个经济学范畴的事情，应该合理安排所有这些步骤的投入。我认为对核心代码走查，对重要代码单元测试，用例制而不要太看重各覆盖率指标。

5单元测试的平台

           单元应该与平台、支撑尽量解耦，在调试方便的windows平台进行。

6单元测试的设计

           介绍单元测试的书有不少，此处推荐《Design by Contract原则与实践》（Richard Mitchell与Jim Mckim）一书。

           于此节选其中一个实例供大家参考。虽然是Eiffel语言写的，但绝对不会影响理解其思想。

7可测试性的提高

           单元测试的可测试性，无法在代码编码完成后再进行提高，是要在设计阶段就要预先考虑的。也就是说，可测试性是设计出来的。

           具体方法，请参看《测试驱动开发》（Kent Beck）。一书之言，恕我无法数言以概。