[微服务下的测试第二季] 痛点与老系统测试

事情是，旧的服务水平测试不是很容易阅读或理解，而且他们需要很多工作来维护。 图形用户界面测试更好的形状，使用现代工具，具有良好的结构。 但实际上，GUI测试总是很昂贵的维护和运行，事实证明，我们系统中的许多功能主要是通过API提供的，而不是用户界面。

我认为我们也许应该考虑扩大我们的服务层API测试，以覆盖新的微服务。 当我们试着用不同的方法来做到这一点时，当我们用这些旧的测试碰到了杀手级的问题 - 当我们在新的微服务架构中运行它们时，它们突然慢了10倍！

当测试可以在与整个单片系统相同的JVM上运行时，一切都很好。 测试使用RMI调用访问功能。 就像魔术一样，应用程序服务器将所有这些远程调用转换为本地调用。 当我们介绍微服务时，这一切都改变了。

我们不得不在其所有其他Docker容器中部署这个Monolith，而且这个测试突然间在一个不同的JVM中。 所有这些数百个RMI调用立即变慢了一个数量级，因为应用程序服务器不再优化它们。 而且，我们发现每次重建系统时都必须重新构建测试，因为RMI调用的客户端必须与服务器版本完全匹配。 管理起来相当困难，测试不再需要20分钟的时间，更像是2小时。

所以我建议我们应该建立一个新的API测试套件，这个测试套件将被设计成从头开始在微服务架构中工作。 他们应该跑得更快，维护成本更低，并且在失败时更容易找到根本原因。