集成测试的“面子”和“里子”

测试积点老人

程序是“分层”的，我们要探讨的是集成测试针对的层面问题。本文所谓的“面子”(Top Level API)指的是程序的最上层接口，也就是被UI或外部系统直接调用的类和方法。“里子”(Lower Level Classes/Methods)就是工作于最上层接口之下，为最上层提供服务的所有下层类和方法。

在谈到集成测试的时候，我们得先来说说单元测试。任何系统都是由一系列相互依赖的类和方法构成的，单元测试的初衷是针对某个类和方法进行“独立”的测试，如果被测试的对象依赖到其他类和方法，则使用mock的方式来隔离被依赖对象对测试的影响。例如某测试对象A依赖另外一个测试对象B，如果我们在测试A的过程中，使用了一个输入与输出均设定了期望值的B的仿制对象，那么这是标准的单元测试，如果我们没有对B进行仿制，那么对于A的测试实际上是对A及其依赖对象B的一次广义上的集成测试！所以对比较地说，单元测试是排除了一切干扰和不确定因素，特别是其他依赖对象的影响，而对某个类和方法进行的“单独”测试，而如果一测试中没有排除掉这些干扰，引入了哪怕是一个非经测试的依赖对象，我们都可以将其看作是“广义“上的集成测试，当引入的依赖越来越多，上升到对其他子系统和模块的依赖时，这时就是我们一般意义上所指的“集成测试”了。

所以我们可以看到集成测试是有层次的，从下至两个相互依赖类之间的测试到上至模块和系统之间的集成测试，都是可以进行的，这里有一个如何把握这种层次或者说是粒度的问题，这就是本文想要阐述的一种易于拿捏和切割的规则：“面子”是一定要测的，“里子”可以视目标类和方法的复杂程度和重要性有选择的进行，对“里子”的测试只是为准确找出引起最上层也就是"面子"问题的准确位置而进行的相对底层与细粒度的测试，可以说这些测试是过程性的，虽然其本身可以用于验证目标代码的正确性，但其被创建的根本初衷是为了定位引发最上层问题的准确位置而设计的。

从实际的开发工作来看，以往程序员们出于要求或是自我素养，做的大多数是单元测试，集成测试一般交给测试人员以黑拿方式进行，那么有没有需要开发人员写集成测试用例的时候呢？从我的工作经验来看，有很多场景是需要的。一般来说，那些不方便做单元测试的场景就是需要集成测试出马的时候，比如严重依赖容器和外围设施与框架的代码，或者说出于工作量，时间的考虑，开发人员只想以最少的代码驱动已经完成的代码并检查基本功能的时候等等。对于笔者目前正在开发的基于HBase的系统来说就是属于前者，因为对于像基于Hbase的应用程序来说，很多代码严重依赖HBase的基础设施，可能会一些第三方面的mock框架来模拟一个HBase的运行环境，但是从实际工作的效果来看，使用自上而下的广义集成测试是非常有效且易于实现和控制的。从本质上讲，我们这里所谓的广义上的集成测试和单元测试是殊途同归的，目的都是排查代码中的错误，只不过前者偏向于自上而下，由粗到细地方式展开，而后者则专注于最细精粒度的测试上。