整合测试

测试

发布日期: 2019-04-16

如何在微服务架构中编写集成测试？

编写集成测试需要大量的精力。与编写单元测试相比，它花费更多，并且要打开的锁数量要多得多。虽然我们仅通过单元测试保证服务的功能，但我们需要集成测试来保证与其他服务的通信。

当涉及集成时，难度级别会进一步增加，并且还涉及微服务架构。如果您之前编写过Moliolith应用程序的集成测试，则可以更清楚地看到它们之间的区别。

在本节中，我们将研究基于Microservis体系结构和消费者驱动的合同测试方法的系统中集成测试的重要性，这通过为主题带来不同的视角，使我们免于编写集成测试的成本。

为什么我们需要集成测试？

随着微服务架构中服务数量的增加，服务之间的通信和集成数量将成正比例增加。包含10个服务的系统和100个或更多服务相互交谈的系统的复杂性和维护成本无疑将是相同的。

让我们考虑一个由数十个微服务组成的大型企业应用程序。我们有一个名为CustomerService的服务。该服务提供了与我们客户有关的其他服务可能需要的所有服务。因此，应使用该服务将对此服务进行的更改通知其他服务。否则，如果幸运的话，相关服务或不知道此更改的服务将在测试环境中失败。在最坏的情况下，如果正在进行的测试过程未涵盖该服务，则当您在实时环境中失败时，系统会通知您，这是我们想要的最后一件事。

同样，如果为CustomerService还需要其他服务的数据，该服务所做的更改应该也可以用已知的CustomerService。

那么我们如何管理这些变更通知？我们可以用人工手动处理吗？此外，我们是否知道哪些服务会影响我们更改的服务？我们是否需要最新的文档？

如果我们的应用程序包含少量微服务，则该团队中的团队可能很小，您也许可以以某种方式手动进行升级。在这里，我们所说的手动是指将对团队内服务所做的更改直接通知给受更改影响的服务的负责任服务。但是，不幸的是，如果我们谈论的是数十种甚至数百种服务，则无法手动管理它。

补救措施：消费者驱动的合同测试（CDC测试）
我们有一个问题要知道您对微服务所做的最细微的更改如何影响使用该服务的消费者，而CDC测试可能是解决此问题的好方法。

我们可以将CDC方法定义为最简单的形式，因为这两个服务就它们彼此发送的数据格式达成一致。此方法基于即时共享服务提供商或服务使用者所做的每个更改的原理。

实施CDC时最重要的问题之一是管理消费者和提供者服务的团队之间的沟通。通信越断开线，实施CDC就会越困难。因此，最佳方案是所有服务均由同一团队负责。

我们聊了很多，好吧，好吧，猜想您开始考虑如何实现此CDC，我想向您介绍Pact框架。由于Pact的详细实施时间可能会长一些，因此我认为在此处提供有关哪种伤口是软膏，其基本结构和用法的入门级信息是合适的。

契约CDC测试框架

让我们先看一下Pact的官方资料。

Pact是一个由消费者驱动的合同测试框架。Pact诞生于微服务的繁荣时期，旨在解决大型分布式系统的集成测试问题。

Pact 是由Pact Foundation使用Ruby语言开发的开源CDC测试框架。它支持多种语言，例如Php，Go，C＃以及Ruby。如果查看Pact Fodundation的github页面，您会看到它在每种语言的单独存储库中进行。

现在，让我们看一下如何逐步实现而又不涉及太多技术细节和代码部分。

情境
我们有一个名为CustomerService的服务，以及另一个使用此服务的ProductService的服务。在这里，他们扮演CustomerService Provider和ProductService作为Consumer的角色。换句话说，CustomerService的更改是否影响ProductService至关重要。

1-在消费者服务端创建合同

如果我们正在创建测试项目，则无法担任服务的productervi角色的使用者。通过确定我们要编写测试场景，我们写我们的单元测试按照格式被确定PactNet和我们提供的服务模拟。在这里，单元测试语句应该引起您的注意。我们从一开始就说集成测试，您可能想知道，它来自哪里？

使用CDC，我们脱离了经典的Integration Test编写格式。如您所知，通常Integration Test方法实际上执行与Unit Tests不同的Web服务或数据库访问。因此，不涉及任何嘲笑。CDC yi Pact由作者在单元测试，提供程序服务中实施，而我们却无法接受，因为我们不再与重要的合同是我们之间的提供程序协议。

消费者，提供者 ‘将被X请求相应的Y接受使用FLUENT提供的方法在Pact所指类型的测试类单元中的响应。

2-创建协议合同（合同）并与提供者共享

消费者测试在文章侧的所有测试方法之后运行。运行测试后，需要创建json格式的Contract。该json文件将在配置Pact时指定的目录中创建。该json文件将随着测试方法中的每一次更改而自动更新，并且始终会在指定目录中进行更新。换句话说，Pact处理合同的不断更新，这是一个非常重要的问题。

生成的文件为json格式且可读性很强的事实使我们甚至可以将CDC应用于结构非常不同的服务。随着供应商编写的围棋语言，一个PHP的消费者可以动摇对他们的契约合同手中。

以下是合同契约示例。在“ 交互”列表下具有两个交互意味着要编写两种测试方法。请求部分消费者然后要求而作出响应。如果对请求消费者的供应商 “，是指从响应的期望。如您所见，它实际上是一种清晰的格式，不需要解释。资料来源：https : //github.com/tdshipley/pact-workshop-dotnet-core-v1

{
“消费者”：{
“名称”：“消费者”
}，
“提供者”：{
“名称”：“提供者”
}，
“互动”：[
{
“ description”：“具有无效日期参数的日期验证的无效GET请求”，
“ providerState”：“有数据”，
“请求”：{
“ method”：“ get”，
“ path”：“ / api / provider”，
“ query”：“ validDateTime =哈哈兹”
}，
“响应”：{
“状态”：400，
“标题”：{
“ Content-Type”：“应用程序/ json; charset = utf-8”
}，
“身体”： {
“ message”：“ validDateTime不是日期或时间”
}
}
}，
{
“ description”：“用于日期验证的有效GET请求”，
“ providerState”：“没有数据”，
“请求”：{
“ method”：“ get”，
“ path”：“ / api / provider”，
“ query”：“ validDateTime = 04/04/2018”
}，
“响应”：{
“状态”：404，
“标题”：{
}
}
}
]
“元数据”：{
“ pactSpecification”：{
“ version”：“ 2.0.0”
}
}
}

3-通知提供商合同

在最后阶段，我们需要告知我们的提供商希望与他签订合同的消费者，并提供有关协议保留位置的信息，以便我们的提供商知道哪个消费者在他进行的任何更改中都会受到影响。

我们可以使用Pact提供的流利方法轻松地做到这一点。我们可以为提供者定义任意数量的消费者和契约网址。在讨论代码细节之前，让我们在总结主题之前最后讨论一下Pact Broker概念。

什么是契约经纪人？

我们将在与提供者共享的部分中配置 “ 契约 ”时确定的目录中创建 json格式的合同。’我们说。在使用者和提供者处于同一环境中的情况下，将合同存储在目录中将很有用，但是在现实生活中，您将必须在Internet上即服务器上共享此文件。公约为我们提供了两种可能性。我们要做的就是指定json文件的位置，而不是目录，写上Pact Broker的地址，以及凭据信息（如果有）。对使用者和提供者执行相同的过程。现在，我们的服务将能够与在互联网上公开或私有的合同握手。

如果您希望将Pact Broker服务作为SaaS获得，则还可以提供官方服务。您可以通过访问https://pactflow.io/查看它。如果您打算认真使用Pact，建议您使用Pact Broker。

此外，Pact Broker的界面非常不错，可以查看合同和数据的最新状态，例如哪种服务取决于哪种服务。作为示例，我总结了我从Pact Broker的github页面获取的两个屏幕截图。

Pact Broker