微服务架构的测试策略(3)

前文所述两种风格的单元测试都在微服务中发挥着重要作用

服务通常是一个由管道和协调代码包围富领域。

域逻辑往往表现为复杂的计算和状态转换的集合。由于这些类型的逻辑是高度基于状态的存在，试图隔离这些单位的意义不大。这意味着尽可能，真正的域对象应该用于所有需要测试的单元。

至于管道代码，则既难以将其与外部模块隔离，又难以根据状态变化进行测试。正因为如此，使用测试替代（test doubles）更为有效的。

这一级的单元测试目的是为了验证用于产生从外部的依赖关系的请求或映射响应的逻辑，而不是以综合的方式检验通信。正因为如此，使用测试替代代替外部依赖使得可以将请求响应周期控制到可靠并且可重复。

在这个级别的单元测试比集成测试提供了更快的反馈，并且可以通过替代部分模拟外部依赖在特殊情况下的响应来强制找出错误状况。

协调逻辑更关心模块之间传递的消息，而不是这些模块中复杂的逻辑。使用测试替代允许对传递消息的细节进行验证以及响应存根，使得测试可以指定模块间的通信。

如果一块协调逻辑的需要太多替代，它通常表明了应该对一些概念进行提取和隔离测试。

当一个服务的大小减小时，使得域逻辑复杂度增加的管道和协调逻辑的比例也相应增加。同样，一些服务包含了全部的管道和协调逻辑，例如不同的技术的适配器以及包含其他服务的聚合器。

在这种情况下，全面的单元测试可能并不适用。其他级别的测试，如组件测试可以提供更大的价值。

单元测试和一般测试的目的是为了约束被测试单元的运行状况。然而有时，测试也制约了实现。这往往体现在依赖模拟基础的方法上。

不断考虑一个单元测试所提供的价值与它的维护成本或它所制约的实现是很重要的。通过这样做，能够保持测试套件小，聚焦以及高附加值。

仅仅单元测试并不能保证系统的行为

到目前为止，我们的测试覆盖了每个孤立的系统核心模块。然而，并没有覆盖到当这些模块一起工作，构成一个完整服务的情况，或是涉及到有远程依赖的情况。

为了验证每个模块能够正确的与合作模块进行交互，更多粗粒度测试是必需的。

集成测试通过验证通信路径和组件之间的交互以检测接口缺陷。

集成测试将模块组合起来，以验证它们根据要求合作并能够实现一些更大规模的行为。他们通过对子系统的通信路径进行彻底测试，来检查各个模块是否有任何与其他模块通信时不正确的假设。

这就与单元测试完全不同，即使单元测试中使用了真实的合作模块，其目标是针对被测试模块运行状况进行仔细测试，而不是测试整个子系统的行为。

虽然测试集成组件或模块时时常可写入任意的粒度，但在微服务架构中，它们通常用于验证集成代码层与其所集成的外部元件之间的交互作用。

这种集成测试对于各种外部元件，例如其他微服务，数据存储和高速缓存来说也可能会有用。

（待续）

{测试窝原创译文，译者：大头}

译者简介：大头，在读日本九州大学修士，计算机专业，主研究方向为文本挖掘，及自然语言处理。