单元测试，对软件在设计的最小单元中进行正确性检测的测试，将可能存在的错误在最小范围内发现并解决。
对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。当然，在具体的测试实现中，也可能对应的是多个程序文件中的一组函数。
单元具有一些基本属性，如明确的功能、规格定义、明确与其他部分的接口定义等，可以清晰的与同一程序的其它单元划分。
执行单元测试的目的
发现模块内部逻辑、语法、算法和功能错误。
单元测试主要是基于白盒测试：
- 验证代码与设计相符度。
- 发现设计和需求中存在错误。
- 发现在编码过程中引入的错误。
单元测试环境
单元本身不是一个独立的程序，一个完整的可运行的软件系统有若干个单元组成，所以必须为每个单元测试开发驱动单元和桩单元。
- 驱动单元（Driver）：所测函数的主程序，它接收测试数据，并把数据传递给所测试单元，最后再输出实际测试结果，当被测单元能完成相关单元时，也可以不需要驱动单元。
- 接收测试数据，包含测试用例输入和预期输出。
- 把测试用例输入传送给要测试的单元。
- 将被测单元的实际输出和预期进行比较，得到测试结果。
- 将测试结果输出到指定的位置。
- 桩单元（Stub）：用来代替所测单元调用的子单元。
- 桩单元的功能是从测试角度模拟被调用的单元。
- 桩单元需要针对不同的输入，返回不同的期望值，模拟不同的功能。
驱动单元执行被测函数得到实际的测试结果，那被测函数可能有其他依赖的函数，我们就要使用桩函数替代被测函数依赖的函数，驱动单元的执行依赖桩函数的正确性。
在展开测试的时候，有相应的测试策略可以使用。
插桩
单元测试的测试策略
孤立的测试策略
不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块，每个模块进行独立的单元测试。
优点是：
- 该方法最简单，容易操作。
- 可以达到很高的结构覆盖率。
- 可以展开并行。
- 该方法是纯粹的单元测试。
缺点是桩函数和驱动函数工作量很大，效率不高。
自顶向下测试测试策略
方法是先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块，其次对于第二层进行测试，使用上面已经测试的单元做驱动模块，如此类推直到测试完所有的模块。
优点是可以节省驱动函数的开发工作量，测试效率高。
缺点是随着被测单元的增加，测试过程变得越来越复杂，并且开发和维护成本将增加
自底向上的测试策略
方法是先对模块调用层次图上最底层的模块进行单元测试，模拟调用该模块的模块做驱动模块，然胡再对上面一层做单元测试，用下面已被测试过的模块做桩模块，一次类推， 直到测试完所有的模块。
优点是可以节省桩函数的开发工作量，测试效率高。
缺点是不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产生很大的影响。
