如何生成“连贯的数据”用于自动化测试？

[uiosun]

用上自动化测试之后，项目 bug 率降低了不止一个层级，而且几乎不再重复暴露。

但现在有一个新的问题，我需要生成一系列的数据，进行一个用例的测试，场景：

1. 在城市 R
2. 玩家 A 建造了建筑 1 ；
3. 并发布了建筑 1 的相关工作招聘 1 ；
4. 玩家 B 前往应聘，并获得了一份工作 1 ；

现在需要测试：“结算工作——玩家 B 获得工资、玩家 A 获得产出，还需要交税给本地城市”。

按我的想法，每个用例需要生成“城市 R 、玩家 A/B 、建筑 1 、招聘 1 、工作 1”，这些数据还需要是连在一起的。

所以目前，我维护了一套这个用例的 sql ，但问题是，随着需求场景越来越多，我已经维护了五六套不同场景的 sql 了，未来还会继续扩增。

如果某天再来一个“base feature change”，可能要改一大批这类 sql 。

有什么办法可以改变这种情况？

---

大佬们，快伸出你们的圆手！;)

[uiosun]

自己顶顶吧，为啥没人回答啊，收藏都有了，第一次遇到这种情况……

期待大佬们的圆手！

[LemonK]

a.自动化测试的 before 方法里调用前置业务 api 临时生成数据。
b.在存储层加个 hook ，按场景维度分好类输出 sql ，随时导出最新套路。
都需要随机生成一些关键字段，比如用户注册信息什么的。

[uiosun]

@LemonK 谢谢大佬的热心回复

现在只能往 b 靠拢，a 与框架自带的一些 mock 机制冲突，浪费了两天，都没实现……
每次遇到这种事，都感觉自己是技术菜鸡，大佬们玩泥巴，捏扁揉圆；我玩的是混凝土墙，头槌都没用😂……

[LemonK]

@uiosun

在现成代码里追加自动化测试肯定有麻烦，不好解决很正常。最好在设计架构的时候就考虑到可测试性。

你说的用例可能是：从表里读取数据 -> 判断处理 -> 从其他表里读取数据 -> 处理 -> 保存。这种数据很难 mock 。

容易测试的方式：调用数据管理层构建对象 -> 业务逻辑 -> 修改对象 -> 业务逻辑 -> 调用数据管理层保存。

上层方法不关心表结构数据来源，只和业务对象打交道。测试主要测逻辑，mock 对象就可以了。