单元测试技术需要解决的问题

有许多的单元测试技术和工具，综合起来，无非是为了解决以下问题。

u  驱动（Driver）—驱动被测单元

单元不能独立运行，必须实现调用它们的代码，我们称其为驱动代码，其实最简单的驱动就是实现main方法，大家常用的驱动典型工具就是JUnit。

u  构建桩（Stub）—模拟被测单元依赖的对象

被测的孤立单元通常会对其它对象有依赖，这种依赖通常表现在：依赖对象通过被测方法参数传入或者被测对象保存有依赖的对象引用，然后在被测方法中调用了依赖对象的方法。构造依赖对象，一方面我们可以直接将开发完成的并且之前已经过单元测试的代码直接拿过来用，另一方面，也是更常用的方法，就是自己构建模拟对象，我们称其为桩，但自己写桩很麻烦，工作量大，现成构建桩的理想工具是EasyMock。

u  验证（Verify）

用例执行是否成功，需要在测试中添加验证点，需要将预期结果与测试执行获得的实际结果进行比较，为此JUnit为我们提供了验证的基本逻辑框架，其它工具可以基于它实现更复杂的验证逻辑，如DBUnit实现的对数据库表数据的验证。

u  用例管理

常有同事提到用main方法也能实现对被测单元的驱动，但我觉得最大的不足是无法实现对用例的有效管理，为此JUnit为我们提供了用例管理的基础框架，通过引入测试套的概念将用例有效地组织起来。

u  结果输出（Report）

测试结束后要能够将本次运行的结果情况形成报告，并以图形化直观的形式报告给用户。JUnit也为我们做到了，尤其是IDE与JUnit的集成，使我们在开发过程中做单元测试变得更加方便。

u  覆盖率检查

公司要求被测代码要求达到语句的100%覆盖，是否覆盖到了，我们可以借助覆盖率检查工具，做测试执行的同时进行覆盖率检查，对未覆盖到的代码可能会发现两类问题：不可达代码，这样的代码需要优化；用例设计不充分，这时就要及时补充用例。常用的覆盖率检查工具有PureCoverage、Cobertura。

u  测试自动化

实现测试自动化的好处大家都很明白，方便回归测试，节省了工作量；另一个好处是便于对测试的监控，这一点我们在后面会谈到。我们模索系统测试自动化已有多年，但效果都不理想，主要原因我觉得和系统测试本身的特点有关，因为系统测试是站在用户角度看系统功能的整体表现（这其中最讨厌的是我们经常还有需求变更，如何做到以不变应万变，我们曾经尝试过，但效果均不理想）。但单元测试不同于系统测试，单元不能独立运行，需要我们实现驱动代码，它的这个特点决定了实现单元测试自动化是非常容易也是顺理成章的