这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「217」篇原创敬上

大家好，我是Z哥。

最近在工作中学习到一个我觉得很有价值的小工具，在这里与大家分享一下。

这个小工具需要自己稍作开发，并不存在什么第三方的现成工具供你使用，因为这个工具的核心关键是「数据」，而「数据」这个东西对于不同的项目天然是不同的。

可能有的小伙伴已经猜到了，我今天要聊的就是一个mock工具（暂且叫这个名字吧，它的能力其实不仅仅只是mock数据）。

多团队协作中，很多功能的实现需要依赖于其它的子系统。这不但影响开发进度，还会导致测试工作开展不太顺利。这个问题在涉及多团队协作的分布式系统中尤其突出。

如果每个子系统都能够内置一个mock工具（模块），通过数据的自动生成，导入和导出，可以灵活地在不同环境上快速地让系统run起来，哪怕自己还没有真正地完成内部的业务逻辑代码编写。

可能你会觉得说，现在很多工具都支持根据定义的API自动生成mock数据啊，postman、apifox、yapi等等，为啥还要自己搞呢。

最大的价值在于以下几点：

1. 这种方式支持在不同环境提供一份相同的数据（如唯一id等等），便于对相关的上下游系统屏蔽掉环境不同的影响。而使用上面提到的工具很难实现这点。
2. 导入和导出功能可以作为在没有打通上下游系统之前的手动关联上下游系统的一种方式。
3. 自动生成的数据可以针对多个API进行共享使用，以模拟“上下文”的感觉，让mock这件事变得更加贴近真实，而不是很假，不管输入的参数是什么，都只能固定返回某个数据。
4. 基于上面第3点，我们可以再通过某种语法，串联起多个API的调用，快速验证mock出来的数据是否符合预期。并且这个串联调用的case可以保存下来，在真实的业务逻辑实现后再运行一下，快速验证自己的真实实现是不是存在什么bug。相当于同时编写了一个针对该项目定制的自动化测试工具。
5. 基于上面第4点，可以不断地丰富case，以提高case所覆盖的场景。这不但丰富了数据样本，也提高了使用该工具进行自动化测试的效果。

总体来看，这样一个工具我们在实现的时候需要具备以下这些能力。

1. 自动生成mock数据
2. mock开关
3. mock数据的条件匹配
4. mock外部依赖数据

下面我们一个个展开说说。

/01 自动生成mock数据/

自动生成mock数据是这个工具的最核心功能。但在这之前还有一件更加重要的事情要做，就是：需要提前确定对外提供的 API 契约，如此才能得到相应的输入和输出参数。然后我们再考虑如何生成mock数据的事情。

当然，生成的数据必须要符合契约定义中的标准。比如，

• 字段的格式。int32还是int64？字符串的格式等等。
• 入参和出参的相关性，比如输入参数中传入的单据号，应该与输出参数中的单据号保持一致，以体现输入和输出之间的相关性。

其次，生成的mock数据，需要尽可能地覆盖更多的场景。

另外，生成的mock数据中如果存在一些依赖于外部系统的唯一ID，允许传入一个ID生成器的hook，确保生成的Mock数据中的唯一ID在指定范围内。

然后，生成的mock数据需要持久化到硬盘上，以提供长期使用。

最后，可以指定生成某个API相关的mock数据，而非全部数据。

/02 清除数据/

可以通过清除数据，重置mock数据回到初始状态，以清理不符合当前API标准的垃圾数据。实现这个功能主要有两个点：

清除数据时需要考虑数据间的关联关系，比如清除单据类数据时，也应当清除与该单据相关的明细数据。

可以指定清除某个指定API的mock数据，而非全部数据。

/03 导入数据/

通过配合导入mock数据功能，快速复制出一个完全相同的mock环境。实现这点也有两个点：

可以导出指定API的mock数据，而非全部数据。

导出的数据建议为csv或者excel格式，便于二次编辑。

/04 导出数据/

通过配合导出mock数据功能，快速复制出一个完全相同的mock环境。

导入数据时，需要进行数据合法性验证。如果数据不合法，需要进行处理，有两种情况：

1. 缺失的数据，如果可以自动填充缺省值，则自动修正。
2. 非法数据或者无法自动填充的缺失数据，进行相应的提示。

/05 mock开关/

通过控制开关，灵活切换使用真实业务存储中的数据还是使用Mock存储中的数据。

/06 mock数据的条件匹配/

可以对mock数据的返回内容进行「条件匹配」配置，以满足两种能力：

1. 限定返回的数据范围。

2. 实现返回的出参一定与入参存在相关性。

/07 mock外部依赖数据/

可以将以上能力运用在所依赖的外部数据上，以提供系统「无依赖独立运行」的能力。

具备这个能力后，你所负责系统的测试工作可以不用等待所依赖的外部系统全部都准备就绪后才能开展，可以独立进行。

好了，就这么多。可能有的小伙伴会觉得，要实现这么多能力，得多大工作量啊。

我觉得这个问题不能这么考虑，我们还要考虑这个工具可以节省多少时间。节约的这个时间不仅仅是你自己做自测的时间，还有团队中其他人的时间。而且这个工具可以长期反复使用，时间拉得越长，它所发挥的价值也越大。

惯例总结一下。

这篇呢，Z哥和你分享了一个我认为很有价值的工具，一个需要我们自行开发的mock工具，它可以提升整个团队的长期效能。

这个工具需要实现以下7个能力：

1. 自动生成mock数据
2. mock开关
3. mock数据的条件匹配
4. mock外部依赖数据

我相信，一旦你提供了这个工具，在团队中你将拥有很好的人缘和口碑～

不知道你是如何看待类似的mock工具的？欢迎和大家一起聊聊你的看法～

---

原创文章，转载请注明本文链接: https://zacharyfan.com/archives/1545.html

关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描二维码~

定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。

如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。

如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。