我刚学了一个新术语,叫做consumer driven contract testing。
我在想,也许它可以帮助我解决我的问题,写测试的一个djangoapi提供者和React前端架构项目。
前端和Django API后端位于不同的库中,并且有各自的单元测试。
但是,偶尔会出现错误,因为前端使用了一些Django服务后端没有返回的字段。
我最初考虑过编写端到端测试,但它们运行速度慢,而且非常脆弱。
我发现了这个消费者驱动的合同测试,它听起来像是正确的事情。但当我谷歌周围,我找不到任何合适的。甚至Pact似乎只是为了转换合同到消费者测试。
在这种情况下,有什么合适的简单方法来进行消费者驱动的合同测试?
2条答案
按热度按时间h9a6wy2h1#
Kim,听起来你在寻找API集成测试,而不是真正的端到端测试。
正如你所说的,使用pact的价值在于获得可以被提供者验证的合约。pact的运行方式和你的单元测试完全一样。如果你在你的前端应用中遵循pact的步骤,你最终会编写单元测试调用提供者(你的django API),建立你期望从每个调用中得到的请求和响应。
默认情况下,Pact会启动一个模拟服务器,它会将react前端应用中的Pact测试(消费者测试)发出的请求指向该服务器。这些测试一旦执行,就会在json中生成Pact文件。然后,API会执行这些Pact文件,这样API就知道它没有破坏前端。
看起来你正在尝试使用Pact进行集成测试。Pact不是合适的工具,因为你所需要的只是一个调用Django API来验证响应的测试。没有简单的方法可以让契约测试启动并全速运行。尽管开始很容易,但如果没有正确的设置,你将无法拥有所有你需要的东西,而且它还涉及到devops工作。
每当我需要测试与Pact外部API的集成时,我所做的是:
快速示例:假设您有一个允许用户创建配置文件的功能。
这个方法包含了你所有的逻辑。
然后,您将对每个getUser、getCurrentLocation、createUser进行一个API集成测试,而对更广泛的createNewUserProfile则不需要进行一个API集成测试,因为如果您有多个由业务逻辑包围的调用,则要找出失败的原因将困难得多。
请告诉我,如果例子是不够好,随时给予我们更多的例子,这样我就可以帮助更详细的信息。
祝你好运!
sqserrrh2#
消费者驱动的契约测试只是在消费者和提供者之间实施API契约的一种方式。
此外,IMHO集成和端到端测试是非常晚的反馈周期,缓慢和昂贵的维护。
为了让消费者和提供者在不进行端到端测试或集成测试的情况下保持良好的协作,您可以利用Contract Driven Development。
在合同驱动的开发中,您将
披露:我是Specmatic的CTO