ASP.NET Core扩展库之Http请求模拟功能的使用

    如今，完全独立的业务应用几乎不存在，不管是在企业内部微服务之间的调用，还是与外部第三方服务的调用，http的api交互是常见的场景，这些实际情况给我们的开发带来了比较大的挑战，一是第三方服务可能会牵制我们的开发进度，特别是在多团队开发的情况下，由于依赖于其他团队的服务，有时候需要等待其他团队的进度，导致自己团队的无效等待。有时因为其他团队的延期，导致团队的被动延期。二是第三方服务的质量问题或开发过程中的频繁更新导致的部署问题，将严重拖累自己团队的开发进度，同时让你无法专心的开发自己的服务。三是单元测试困难，特别是在依赖于多个第三方服务时，使得单元测试可能依赖于其他服务环境，导致单元测试结果的不确定性。

    为了解决以上这些问题，xfrogcn.aspnetcore.extensions扩展库提供了http请求模拟的功能，通过此功能可以让你在开发、单元测试时实现你的服务与第三方服务的完全解耦，让你能够更聚焦于自己服务的开发。

    http请求模拟构建在.net core httpclientfactory架构之上，通过在httpclient请求管道中替换实际发送http请求的主消息处理器为模拟消息处理器来完成请求的模拟应答。

一、在服务端使用

    假设我们负责开发一个订单服务，在订单提交接口，我们保存完订单数据之后，需要发送消息通知，消息通知的发送由消息服务来实现，该服务由另一团队负责，如下图所示：

    由于订单服务依赖于消息服务，在项目启动时，一般两个团队会协商好消息服务的接口定义，然后消息服务团队会快速搭建一个空接口供订单服务团队调用，如果是这种流程，订单服务团队只需等待消息服务团队搭建好环境即可开始工作，好像影响不大，但在实际开发过程中，会存在以下现实的问题：

• 虽然消息服务团队提供空接口的时间不长，但是如果项目工期紧张，计划都是以小时计算，那么这也将影响订单服务的开发进度
• “空消息服务”实际上无法一直保持空的状态，消息服务团队会不断对服务进行更新加入他们的实现逻辑，而消息服务本身也可能依赖于其他的服务，这导致订单团队所使用的消息服务不稳定，那么订单团队的进度实际上还是会受到消息服务团队，以及消息服务所依赖的其他团队的影响。
• 订单服务团队可以使用空的消息服务，但消息服务团队往往需要连接企业外部的第三方服务，比如app的消息推送通道，这让整个项目依赖更加复杂。
• 订单服务团队编写单元测试会比较困难（当然，此点可以通过抽象来解决，但结合扩展库的http请求模拟功能，我们可以简化此过程）
  

    以下介绍如何使用扩展库的请求模拟功能。

    为了聚焦于模拟功能的演示，该示例进行了简化，比如与消息服务的通讯，在正式项目中会通过消息服务的sdk来完成，示例中将直接使用httpclient，有关sdk与扩展库的结合，我们将在后续文章中说明。

1.引用xfrogcn.aspnetcore.extensions
2.定义订单类

3.定义消息发送请求类

4.配置
    在starup configureservices方法中配置模拟

    注意，以上通过配置中的mock属性来决定是否开启模拟功能，为了不影响正式发布，可以通过开发环境配置(appsettings.development.json)来开启模拟：

5.控制器

6.启动，然后通过api测试工具（如postman）向/api/order post请求，接口将返回以下应答：

    如上，通过http请求模拟，我们实现了订单服务对消息服务的依赖。

二、在单元测试中使用

    单元测试中，针对模拟应答的配置是一样的，我们可以通过测试用例模拟各种不同的应答，包括异常，来对执行路径进行测试。

三、示例

    详细示例请参考github

    xfrogcn.aspnetcore.extensions地址：github gitee

以上就是asp.net core扩展库之http请求模拟功能的使用的详细内容，更多关于asp.net core http请求模拟功能的使用的资料请关注其它相关文章！