网站毕业设计开题报告,百度竞价排名规则,系统炸了我成了系统,wordpress展示企业主题免费下载消费者驱动的契约测试相当早以前#xff0c;我们从REST#xff08;ful#xff09; Web API的角度讨论了消费者驱动的合同测试 #xff0c;尤其是将其投射到Java#xff08; JAX-RS 2.0规范#xff09;的角度。 可以公平地说#xff0c;至少在公共API方面#xff0c; RE… 消费者驱动的契约测试 相当早以前我们从RESTful Web API的角度讨论了消费者驱动的合同测试 尤其是将其投射到Java JAX-RS 2.0规范的角度。 可以公平地说至少在公共API方面 REST仍在Web API领域占据主导地位但是向微服务或/和基于服务的体系结构的转变正在Swift改变力量的一致性。 这种破坏性趋势之一是消息传递 。 现代的RESTful API主要通过HTTP 1.1协议实现并受其请求/响应通信样式的限制。 这里提供了HTTP / 2的 帮助但并不是每个用例都适合此通信模型。 通常该工作可以异步执行并且可以稍后将其完成的事实广播给感兴趣的各方。 这就是大多数事物在现实生活中的工作方式而使用消息传递是对此的完美答案。 消息传递空间确实挤满了惊人数量的消息代理和可用的无代理选项。 我们将不讨论这个问题而是关注另一个棘手的主题消息契约。 生产者发出消息或事件后它将进入队列/主题/频道准备被使用。 它在这里停留了一段时间。 显然生产者知道它所发布的内容但是消费者呢 他们怎么知道会发生什么 此刻我们许多人会大喊使用基于模式的序列化 的确 Apache Avro Apache Thrift 协议缓冲区 消息包 …可以解决这个问题。 归根结底此类消息和事件以及RESTful Web API如果有将成为提供者合同的一部分并且必须随着时间的推移进行通信和发展而又不会破坏消费者。 但是……您会惊讶地发现有多少组织在JSON中发现了他们的必杀技并使用它来传递消息和事件 从而向消费者扔出这样的垃圾 而没有任何模式 在这篇文章中我们将研究消费者驱动的合同测试技术如何在这种情况下为我们提供帮助。 让我们考虑一个简单的系统该系统具有两项服务即订购服务和货运服务 。 订单服务将消息/事件发布到消息队列然后运货服务从那里使用它们。 由于Order Service是用Java实现的因此事件只是POJO类在使用大量库之一到达消息代理之前序列化为JSON 。 OrderConfirmed是此类事件之一。 public class OrderConfirmed { private UUID orderId; private UUID paymentId; private BigDecimal amount; private String street; private String city; private String state; private String zip; private String country; } 通常情况下 Shipment Service团队会交出示例JSON代码片段或者指出一些文档片段或参考Java类基本上就是这样。 在确保他们的解释正确无误且所需信息消息不会突然消失的同时货运服务团队如何启动整合工作 以消费者为导向的合同测试得以营救 Shipment Service团队可以并且应该开始针对OrderConfirmed消息编写测试用例并嵌入他们所拥有的知识而我们的老朋友Pact框架准确地说是Pact JVM 是实现此目的的正确工具。 那么测试用例可能是什么样子 public class OrderConfirmedConsumerTest { private static final String PROVIDER_ID Order Service ; private static final String CONSUMER_ID Shipment Service ; Rule public MessagePactProviderRule provider new MessagePactProviderRule( this ); private byte [] message; Pact (provider PROVIDER_ID, consumer CONSUMER_ID) public MessagePact pact(MessagePactBuilder builder) { return builder .given( default ) .expectsToReceive( an Order confirmation message ) .withMetadata(Map.of( Content-Type , application/json )) .withContent( new PactDslJsonBody() .uuid( orderId ) .uuid( paymentId ) .decimalType( amount ) .stringType( street ) .stringType( city ) .stringType( state ) .stringType( zip ) .stringType( country )) .toPact(); } Test PactVerification (PROVIDER_ID) public void test() throws Exception { Assert.assertNotNull(message); } public void setMessage( byte [] messageContents) { message messageContents; } } 它非常简单明了没有添加任何样板。 测试用例是根据OrderConfirmed消息的JSON表示而设计的。 但是我们还只是半途而废 货运 服务团队应该以某种方式将他们的期望回馈给订购服务以便生产者可以跟踪谁以及如何消费OrderConfirmed消息。 Pact测试工具通过将每个JUnit测试用例中的pact文件一组协议或pact生成到“ target / pacs”文件夹中来解决此问题。 下面是运行OrderConfirmedConsumerTest测试套件后生成的Shipment Service-Order Service.json pact文件的示例 。 { consumer : { name : Shipment Service }, provider : { name : Order Service }, messages : [ { description : an Order confirmation message , metaData : { contentType : application/json }, contents : { zip : string , country : string , amount : 100 , orderId : e2490de5-5bd3-43d5-b7c4-526e33f71304 , city : string , paymentId : e2490de5-5bd3-43d5-b7c4-526e33f71304 , street : string , state : string }, providerStates : [ { name : default } ], matchingRules : { body : { $.orderId : { matchers : [ { match : regex , regex : [0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} } ], combine : AND }, $.paymentId : { matchers : [ { match : regex , regex : [0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} } ], combine : AND }, $.amount : { matchers : [ { match : decimal } ], combine : AND }, $.street : { matchers : [ { match : type } ], combine : AND }, $.city : { matchers : [ { match : type } ], combine : AND }, $.state : { matchers : [ { match : type } ], combine : AND }, $.zip : { matchers : [ { match : type } ], combine : AND }, $.country : { matchers : [ { match : type } ], combine : AND } } } } ], metadata : { pactSpecification : { version : 3.0.0 }, pact-jvm : { version : 4.0.2 } } } 发货服务团队的下一步是与订单服务团队共享此契约文件以便这些人可以在其测试套件中运行提供方的契约验证。 RunWith (PactRunner. class ) Provider (OrderServicePactsTest.PROVIDER_ID) PactFolder ( pacts PactFolder pacts ) public class OrderServicePactsTest { public static final String PROVIDER_ID Order Service ; TestTarget public final Target target new AmqpTarget(); private ObjectMapper objectMapper; Before public void setUp() { objectMapper new ObjectMapper(); } State ( default ) public void toDefaultState() { } PactVerifyProvider ( an Order confirmation message ) public String verifyOrderConfirmed() throws JsonProcessingException { final OrderConfirmed order new OrderConfirmed(); order.setOrderId(UUID.randomUUID()); order.setPaymentId(UUID.randomUUID()); order.setAmount( new BigDecimal( 102.33 )); order.setStreet( 1203 Westmisnter Blvrd ); order.setCity( Westminster ); order.setCountry( USA ); order.setState( MI ); order.setZip( 92239 ); return objectMapper.writeValueAsString(order); } } 测试工具从PactFolder中选取所有的pact文件并针对TestTarget进行测试在这种情况下我们将接线提供的AmqpTarget 但您可以轻松插入自己的特定目标。 基本上就是这样 消费者 装运服务 在测试用例中表达了他们的期望并以契约文件的形式与生产者 订购服务 共享了他们的期望。 生产者有自己的一组测试以确保其模型符合消费者的观点。 双方可以继续独立发展并相互信任只要条约不受到谴责希望永远不会。 公平地说 Pact并不是进行消费者驱动的合同测试的唯一选择在即将发布的帖子已经开始工作中我们将讨论另一个出色的选择即Spring Cloud Contract 。 直到今天完整的项目资源都可以在Github上找到 。 翻译自: https://www.javacodegeeks.com/2019/11/tell-us-what-you-want-and-we-will-make-it-so-consumer-driven-contract-testing-for-messaging.html消费者驱动的契约测试
