使用契约测试提高分布式系统的质量.docxVIP

使用契约测试提高分布式系统的质量 两个应用在相互通信前，会正式确定两者间的消息发送和接收方式。我们并非要探讨通信的模式，由于我们并不关注全部可能的恳求和响应字段，以及 HTTP 通信的接收方法。我们想要定义的是可实际发生的会话，称之为“契约”（Contract）。契约是 API/ 消息生产者与消费者之间的共识，它定义了会话的具体方式。 目前有多种实现契约测试的工具，我们认为其中广为接受的只要两种，即 Spring Cloud Contract 和Pact 。在本文中，我们将聚焦于前者，具体引见如何使用 Spring Cloud Contract 实现契约测试。 Spring Cloud Contract 支持以 Groovy、YAML 或 Pact 文件方式定义契约。下面给出的例子使用 YAML 定义契约： description: | Represents a scenario of sending request to /foo request: method: GET url: /foo response: status: 200 body: “OK” 上面的契约中定义了： ·?假如发送一个具有 GET 方法的 HTTP 恳求到 URL 地址“/foo”，I ·?那么前往一个形态为 200、内容为“OK”的响应。 依据 WireMock Stub，我们需要编码实现消费者的测试需求。 只存储这样的会话片段并没有多少意义。假如不能实际验证通信双方能否保持了承诺，那么这样的契商定义与记在纸上的或 Wiki 页面上的毫无二致。Spring 中格外注重承诺。假如一方编写了契约，那么我们需要从中生成测试，验证生产者能否达到了契约的要求。 要实现这样的测试，我们必需在生产者端（即 Customer History Service 应用）设置 Spring Cloud Contract 的 Maven 或 Gradle 插件，定义契约，并将契约置于适当的文件夹结构中。之后，插件将会读取契约的定义，依据契约生成测试和 WireMock Stub。 必需谨记，不同于从前在消费者端（即 Legacy Service）生成 Stub 的做法，现在 Stub 和 测试都是从生产者端（即 Customer History Service）生成的。 下图显示了从 Customer History Service 看到的流程。 那么生成的测试的具体内容是怎样的？下面给诞生成的测试代码： public class RestTest extends RestBase { @Test public void validate_shouldReturnOKForFoo() throws Exception { // 给定： MockMvcRequestSpecification request = given(); // 一旦： ResponseOptions response = given().spec(request) .get(“/foo”); // 那么： assertThat(response.statusCode()).isEqualTo(200); // 以及： String responseBody = response.getBody().asString(); assertThat(responseBody).isEqualTo(“OK”); } Spring Cloud Contract 使用一种称为“ Rest Assured ”的框架，发送和接收测试 REST 恳求。Rest Assured 中包含了一些遵照良好 BDD（Behavior Driven Development）实践的 API。测试是描述性的，它可很好地引用契约中定义的全部恳求和响应条目。那么，为什么在代码中还需要指定基类（Base Class）？ 契约测试在本质上并非是对功能做断言。我们想要实现的是对语法做验证，即生产者和消费者能否可在生产环境中成功通信。 在基类中可建立对应用服务的仿照（Mock）行为，并前往虚数据。例如，把握器可如下定义： @RestController class CustomerRentalHistoryController { private final SomeService someService; CustomerRentalHistoryController(SomeService someService) {