4、为什么要Mock回放：真实依赖带来的问题与Mock的价值
做Android网络层测试久了，你会发现一个挺扎心的事实——你写的测试代码，很多时候不是在测你的逻辑，而是在测后端服务稳不稳。我刚开始用Retrofit写接口测试时，天天被这类问题折磨。今天咱们就把这些坑一个个扒开，聊聊为什么Mock回放能救你。
真实依赖的三大痛点
先说说直接用真实后端跑测试会遇到什么。你想想看，一个接口测试，要依赖网络、数据库、第三方SDK……随便哪个环节出点问题，测试就挂了。我个人总结下来，有三大类问题最头疼。
1. 不稳定——测试结果像开盲盒
网络波动是最常见的。上午还能跑的测试，下午就超时了。你在办公室Wi-Fi下跑得溜，换到地铁上就全红。更离谱的是，有些后端服务在特定时段会限流，比如半夜的定时任务一跑，你的接口就返回503。
我经历过的一个真实案例：有一个订单流程的集成测试，每天凌晨2点到3点必挂。查了半天，原来是后台在做数据备份，把连接池占满了。那时候我才意识到，测试依赖真实环境，等于把主动权交给了别人。
2. 慢——一个测试等几十秒
接口调用本身可能只要200ms，但加上网络握手、DNS解析、SSL协商、后端处理……一轮下来5秒起步。你跑100个测试用例，光等网络就花了10分钟。我习惯在提测前跑一遍全部冒烟测试，如果依赖真实后端，那简直是一种煎熬。
建议：把单元测试的执行时间控制在分钟级以内。如果某个测试动不动就要等，说明它不该呆在单元测试里。
3. 无法复现——Bug重现随缘
最让人崩溃的是：测试报了一个错，但你再跑一遍就过了。这叫“偶发失败”，在依赖真实环境的测试里非常常见。比如某个接口返回了特定状态码，但下一次请求又正常了。你根本没法抓包，没法复现，更谈不上去修bug。
为什么会这样？因为真实后端的状态是变化的。数据库里数据可能在变，缓存可能过期，A/B实验的流量可能切换了……你没办法把后端快照下来。
注意：永远不要用“再跑一遍就过了”来安慰自己。这种偶发失败背后往往藏着更严重的时序或并发问题。
Mock如何一一化解？
好了，痛点说完了，咱们看看Mock是怎么解决这些问题的。说白了，就是用一个假的、可控的后端来代替真实依赖。
| 痛点 | Mock解决方式 |
|---|---|
| 不稳定 | Mock永远返回你预设的响应，不会超时，不会503。测试结果100%可复现。 |
| 慢 | Mock响应在毫秒级，不用走网络。我测过，一个Mock返回耗时通常小于5ms。 |
| 无法复现 | 你可以精确控制Mock返回什么。想测错误码？直接配置一个500响应回来。想测边界值？让Mock返回空列表或超大JSON。随便复现。 |
我记得有一次，需要测试“过期后自动刷新”的流程。在真实环境中，你得等真的过期，耗时至少1小时。用Mock的话，我直接让第一个接口返回401，然后验证重试逻辑是否调用了刷新接口——整个过程不到2秒。效率提升不止一个数量级。
录制回放的适用场景
Mock虽好，但也不是万能药。手工写Mock数据太累，而且容易跟真实接口行为脱节。这时候就有了“录制回放”这种策略——你先跟真实后端交互一次，把请求和响应录下来，以后测试就回放这些录好的数据。
那什么时候该用录制回放？我总结了一张表，供你参考：
| 适用场景 | 不适用场景 |
|---|---|
| 第三方API调用（如支付、短信、地图） | 对实时性要求极高的场景（如股票行情、聊天） |
| 后端接口不常变、版本稳定的项目 | 接口频繁变更的开发初期阶段 |
| 回归测试、冒烟测试 | 需要验证新接口逻辑正确性的场景 |
| 离线测试（无网络环境或弱网环境） | 需要测试后端最新数据的场景 |
| CI流水线中快速执行的自测 | 需要端到端全链路验证的集成测试 |
我个人的习惯是：新功能开发阶段用手写Mock，因为接口还在改，需要频繁调整返回值；测试稳定后切换到录制回放，用真实交互的数据来保证Mock与后端行为一致。一旦发现录制数据和真实行为有差异，就重新录制一遍。
一个小技巧：录制回放最好搭配“差异比较”工具。比如把回放的响应和真实响应做字段级对比，这样能自动发现接口是否发生了破坏性变更。
最后再多说一句：不要以为用了录制回放就万事大吉。我记得有一次，后端偷偷改了某个字段的类型，从字符串变成了数字，录制数据没更新。结果测试全部通过，上线后前端直接崩溃。所以录制回放只是一个提效工具，定期重新录制和人工审查仍然必不可少。
核心思想：Mock回放不是要抛弃真实测试，而是把不稳定的依赖因素隔离出去，让测试更快、更稳、更可控。至于那些必须依赖真实环境的场景（比如压力测试、性能测试），该交给专门的测试环境去做，别混在单元测试里。