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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

V2EX 提问指南

这是一个创建于 1098 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

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

SQL

玩家

生成

测试

4 条回复 • 2021-11-17 13:59:06 +08:00

uiosun

2021-11-12 13:47:22 +08:00

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

期待大佬们的圆手！

LemonK

2021-11-12 18:03:53 +08:00

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

uiosun

2021-11-15 16:12:11 +08:00

@LemonK 谢谢大佬的热心回复

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

LemonK

2021-11-17 13:59:06 +08:00

@uiosun

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

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

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

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