reactjs 什么是一个适当的方式来设置消费者驱动的合同测试的djangoapi和React客户端?

2ledvvac  于 2022-11-22  发布在  React
关注(0)|答案(2)|浏览(121)

我刚学了一个新术语,叫做consumer driven contract testing
我在想,也许它可以帮助我解决我的问题,写测试的一个djangoapi提供者和React前端架构项目。
前端和Django API后端位于不同的库中,并且有各自的单元测试。
但是,偶尔会出现错误,因为前端使用了一些Django服务后端没有返回的字段。
我最初考虑过编写端到端测试,但它们运行速度慢,而且非常脆弱。
我发现了这个消费者驱动的合同测试,它听起来像是正确的事情。但当我谷歌周围,我找不到任何合适的。甚至Pact似乎只是为了转换合同到消费者测试。
在这种情况下,有什么合适的简单方法来进行消费者驱动的合同测试?

h9a6wy2h

h9a6wy2h1#

Kim,听起来你在寻找API集成测试,而不是真正的端到端测试。
正如你所说的,使用pact的价值在于获得可以被提供者验证的合约。pact的运行方式和你的单元测试完全一样。如果你在你的前端应用中遵循pact的步骤,你最终会编写单元测试调用提供者(你的django API),建立你期望从每个调用中得到的请求和响应。
默认情况下,Pact会启动一个模拟服务器,它会将react前端应用中的Pact测试(消费者测试)发出的请求指向该服务器。这些测试一旦执行,就会在json中生成Pact文件。然后,API会执行这些Pact文件,这样API就知道它没有破坏前端。
看起来你正在尝试使用Pact进行集成测试。Pact不是合适的工具,因为你所需要的只是一个调用Django API来验证响应的测试。没有简单的方法可以让契约测试启动并全速运行。尽管开始很容易,但如果没有正确的设置,你将无法拥有所有你需要的东西,而且它还涉及到devops工作。
每当我需要测试与Pact外部API的集成时,我所做的是:

  • 确保API调用在方法中是隔离的,这样可以方便地对所需的每个单独的API方法调用进行单元测试;这很容易被忽略,并且它导致了复杂的、不可靠的测试,因为您最终不得不在测试用例中放入大量的逻辑,只是为了让它们返回您需要的响应;
  • 创建一个调用该方法测试器,然后该测试器将调用您的API并给予您需要的响应;

快速示例:假设您有一个允许用户创建配置文件的功能。

  • 调用GET /user传递用户id以查看用户是否存在
  • 调用GET /location以获取用户位置信息,以便您可以添加到用户配置文件中
  • 调用POST /user,将用户信息传递到后端以创建用户
  • 返回GET或POST的响应,具体取决于调用哪一个

这个方法包含了你所有的逻辑。

  • 执行getUser并调用GET /user的方法
  • 一个执行getCurrentLocation并调用GET /location函数
  • 一个使用您所拥有的数据调用POST /user的createUser。
  • 重构createNewUserProfile以调用上面列出的方法。

然后,您将对每个getUser、getCurrentLocation、createUser进行一个API集成测试,而对更广泛的createNewUserProfile则不需要进行一个API集成测试,因为如果您有多个由业务逻辑包围的调用,则要找出失败的原因将困难得多。
请告诉我,如果例子是不够好,随时给予我们更多的例子,这样我就可以帮助更详细的信息。
祝你好运!

sqserrrh

sqserrrh2#

消费者驱动的契约测试只是在消费者和提供者之间实施API契约的一种方式。
此外,IMHO集成和端到端测试是非常晚的反馈周期,缓慢和昂贵的维护。
为了让消费者和提供者在不进行端到端测试或集成测试的情况下保持良好的协作,您可以利用Contract Driven Development
在合同驱动的开发中,您将

  • 在API规范中表示Django API后端,例如OpenAPI
  • 利用此API规范作为可执行合同
  • 消费者端-利用你的API规范作为存根来模拟提供者。为前端编写一个组件测试,并连接你的前端来与这个存根对话,从而独立测试你的前端。请参见anatomy of component test
  • 提供方-利用API规范作为“测试合约”来验证Django API后端是否遵守API规范
  • 通过使使用者和提供者都符合通用API规范,您可以保证它们能够很好地协同工作,而不必总是等待集成或端到端测试来确定合同兼容性问题。

披露:我是Specmatic的CTO

相关问题