多服务 - 何时使用模拟和存根?
如果您正在建立结帐,而您的职责仅仅是为了渲染一个带有通常详细信息的确认页面,包括订单号等。
如果您知道有一个服务/API/端点,则您将致电。但是您对合同不了解,甚至谁将提供/werite/同意合同,这是您要么的情况
:合同根本不是由您决定的,因此实际上完成时可能会完全不同) b)暂停开发并等待依赖合同至少在认真开始任何工作之前提出和记录(即使没有实施)
If say you're building a checkout and your remit is simply to render a confirmation page with usual details, including order number etc.
If you know that there is a service/API/endpoint that you will call,. but you have no idea about the contract nor WHO would even provide/werite/agree the contract, would this be a case where you would either:
a) mock what a reasonable endpoint might do, build and test against it (even though the final contract isn't at all up to you and thus could look completely different when it's actually done)
b) pause development and wait for the dependent contract to at least be proposed and documented (even if it's not committed) before starting any work in earnest
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可能会为未知的API调用创建一个抽象层。
这与您的选项相似,但主要区别在于,您可以在到达时尽可能容易地交换实际代码。
这种方法的优点是,如果您将来更改此服务的提供商,它将更容易在新提供商中交换。
缺点可能包括增加代码复杂性和对性能的可能影响。
You could potentially create an abstraction layer for the unknown api calls.
This is similar to your option a), but the main difference is that you make it as easy as possible to swap in the real code when it arrives.
One advantage of this approach is that if you change the provider of this service in the future it would make it easier to swap in the new provider.
Disadvantages may include an increase in code complexity and a possible impact on performance.