前端测试每次执行后清理DB是否合理？如何尽可能避免mock优化测试？

关于测试后清理DB的合理性 #

每次测试后清理DB本身不是错误决策，你遇到的异常本质是测试执行的时序管控漏洞，和清理策略本身无关。
根因是测试用例没有等待所有异步任务执行完成就触发了DB清理流程，才会出现后置请求读到空数据或者写入的数据被误清的问题。
针对这个问题的修复方案如下：

• 测试框架的用例结束钩子（例如Jest的afterEach、Cypress的after钩子）中添加异步等待逻辑：监听所有前端发起的fetch/XMLHttpRequest请求状态，确认所有活跃请求全部返回后，再调用DB清理接口
• 给DB清理逻辑添加范围限制：后端清理接口接收当前测试用例的唯一标识参数，仅清理该标识关联产生的测试数据，避免误清理其他异步请求写入的内容
• 调整清理时机：将清理逻辑从用例后执行改为用例前执行（即beforeEach阶段清理），就算上一轮测试有未完成的异步请求晚到，产生的脏数据也会在新一轮测试启动前被清除，完全不影响当前测试的独立性

低Mock/无Mock的前端测试优化方案 #

不想维护手动mock的前提下，可以参考以下落地成本低、维护量小的方案：

• 搭建专用测试后端环境：部署独立的测试态后端服务，数据和开发、生产环境完全隔离，所有前端测试请求直接请求该测试后端，不需要模拟返回值。仅需要在每条测试启动前给后端传入对应测试场景的初始化数据集即可，后端接口迭代时测试环境同步更新，无需额外维护mock规则
• 采用流量录制回放方案：用工具拦截一次真实环境的API请求响应数据，录制为本地缓存文件，后续测试直接回放录制结果。后端接口有变更时只需要重新录制一次即可，不需要手动修改mock内容，维护成本远低于手写mock
• 测试数据做唯一标识隔离：每条测试用例生成专属的唯一标识，所有测试操作产生的DB数据都携带该标识，不同用例的数据完全独立，不需要每次全量清理DB，仅需要定期批量清理所有带测试标识的历史数据即可，大幅降低清理操作带来的时序问题
• 最小化mock范围：仅对第三方不可控服务（例如支付、短信、第三方登录接口）做mock，内部业务接口全部走测试环境请求，从根源上减少mock的维护量

内容的提问来源于stack exchange，提问作者Noname