针对混乱的调用关系,思路是:我的被测服务就是服务 A,那么我不用管服务 B 是不是好用,只要保障服务 A 能够走完流程,就可以完成接口测试任务了。循着这个思路,只要用 Mock 服务伪装成服务 B 就万事大吉了,我也不用再关心服务 B 到底调用了多少服务。
应该怎么选择 Mock 服务框架呢?
首先,你要基于自己和团队的技术栈来做选择
其次,你要让写好的 Mock 服务容易修改和维护
如果你的团队技术基础很好,开发能力很强,那么我建议你用对应语言的 Mock 框架,例如 Java 语言的Mockito 框架(https://github.com/mockito/mockito)和 Python 语言的mock 框架(mock · PyPI)。
如果你的团队技术基础相对比较薄弱,那么我推荐你看看moco,这个框架在开发 Mock 服务的时候,提供了一种不需要任何编程语言的方式,你可以通过撰写它约束的 Json 建立服务,并通过命令启动对应的服务,这就可以快速开发和启动运行你需要的 Mock 服务。
Mock 服务设计经验
首先,简单是第一要素。无论原服务 B 处理了多么复杂的业务流程,你在设计服务 B 的 Mock 服务时,只要关心服务 B 可以处理几种类型的参数组合,对应的服务都会返回什么样的参数就可以了。这样你就能快速抓住 Mock 服务