Google测试工程师日常工作：构建基础设施才是重点(2)

几年前，我加入了一个工程项目组，主要任务是开发一个新系统替换旧系统。因为构建替换过程需要几年，我们需要保持旧系统正常运行，甚至在旧系统上添加新功能，同时慢慢替换为新系统，这样才不会影响用户使用。

然而旧的系统是如此复杂和脆弱，工程师要花费大部分时间来分类并修复 bug 及进行相关测试，以至于没有时间实现新系统。新系统的目标是实现所有老系统功能的基础上，并使之更容易维护且扩展性更好。作为团队的 TE，我的工作是了解高维护成本的成因及如何改进。

我发现两个主要问题：

• 紧耦合和抽象不足使得单元测试非常困难，因此，需要大量的端到端功能测试来验证所有的代码。

• 端到端测试的基础设施没有机制提供创建和注入 mock 服务的方法。因此，测试必须为所有这些外部依赖关系启动大量服务器。这导致了测试的工作量很大并且很脆弱，现有的基础设施无法可靠地处理这一问题。

解决方案

首先，我尝试将大测试分成更小的测试的可能性，小测试可以聚焦特定几个功能，并减少依赖服务的数量。但是，在结构不良的旧系统代码中，发现这个想法是不可能的，如果要按这种方法工作将需要重构整个系统及其依赖项，这不仅仅是测试团队可以完成的工作。

第二种方法，我尝试进行大的测试，并试图将非测试的功能的调用进行 mock。这最终证明也是非常困难的，因为依赖经常改变，并且单个依赖很难在 200 多个服务中进行追踪。最终，这种方法只是将所需的工作从维护测试代码转移到模拟和维护测试依赖。

我的第三个也是最后一个方法，如下图所示：使小测试用例更加强大。在我们面临的典型的端到端测试中，客户端对几个服务进行了 RPC 调用，这些服务又 RPC 调用了其他依赖服务。客户端和所有后端服务的调用闭包一起形成了一个大的依赖图（而不是树！），这一切都必须在端到端测试中运行。

新模型改变了我们如何对客户端和服务端进行测试，仅运行客户端来执行几个 RPC 调用，然后观察相关依赖调用是否正常的做法不太适合，我们对 RPC stub 的代码编写单元测试，Stub 本身是用一个常见的模拟框架（如 Java 中的 Mockito）来完成的。

原文转自：https://www.testwo.com/article/891