一次私教辅导，从Mock工具到Sidecar：我帮学员拆通了接口自动化的关键一环

一个接口自动化的小问题，聊出了测试左移的大道理。

——霍格沃兹测试开发学社私教服务真实案例

01 一个“卡住了”的问题

本周，霍格沃兹测试开发学社私教学员ZX带着问题来找我：

“老师，我想在接口自动化里Mock第三方的数据，但现在卡住了。”

他的需求很明确：公司服务调用了外部接口，比如微信支付，做接口自动化测试时，希望把这些外部依赖“抹掉”，用Mock代替，让测试能稳定跑通。

听起来是个很常规的需求。

但ZX接着说：“我发现如果用Mock工具，测试环境跑起来之后，其他人也会被影响。”

这是一个好问题。也是很多测试同学从“自己玩Mock”走向“团队级Mock”时，撞上的第一堵墙。

02 Mock是怎么跑起来的？

我问ZX：“你之前用的Mock工具是怎么用的？自己部署的一个服务？”

“对，”他说，“就是一个独立的Mock服务，用JSON配置URL和返回报文，根据请求参数匹配规则。”

“那就对了，”我说，“你现在的做法，相当于起了一个Mock Server，然后让被测应用把请求打到这个Mock上来。”

ZX点头：“但这样得代理测试环境的服务器吧？”

“对，而且刚才说的问题——影响到别人——其实是可以通过请求参数配置来解决的。”

我给他举了个例子：我以前对接金融机构接口时，就用金额来做匹配规则。比如转账4.99元返回一套报文，转9.99元返回另一套。规则公告给所有人，不想命中Mock，换个金额就行。

“懂了。”ZX说。

但这只是第一个问题。

03 K8s环境里，IP会变怎么办？

ZX接着抛出第二个问题：“我们的环境是K8s部署的，每次构建都会销毁之前的容器，IP会变。这个怎么处理？”

“IP会变，那就给它弄一个内部的host。”我说，“这个你们运维同学应该能解决。”

“那我回头找他们沟通。”

到这里，ZX的两个初步问题都有了方向。但接下来，我们聊到了一个更本质的问题。

04 代码里写死，才是最大的坑

“不过，”我话锋一转，“你用Mock工具还有一个前提——你的应用得把接口的host改成可配置的。”

ZX愣了一下：“我们这个好像是代码里写死的。”

“那就不行。”

我解释道：如果应用代码里直接写死了https://api.weixin.qq.com/pay，那无论起多少个Mock服务，它都不会打过去。得让开发改成从环境变量里读取。

“这个……开发应该不会去改。”ZX有点无奈。

“开发不改的话，用Mock就行不通。这种方案是侵入式的，需要代码配合。”

电话那头沉默了一秒。

05 换条路：Sidecar方案

“那我只能用Sidecar了？”ZX问。

“对，可以用Sidecar模式。”

Sidecar是什么？简单说，就是把一个代理程序跟应用放在同一个容器里。它可以在不修改代码的情况下，拦截应用发出的网络请求，然后返回想Mock的数据。

“这个可以集成到Java里吗？”

“可以，它本质上就是一个agent，最后打成一个jar包。把它跟应用放到同一个Docker镜像里，一起拉起来就行。”

“有相关文档吗？我之前搜过没找到。”

“有的，我发群里。”

我找到了阿里开源的Sidecar资料。外面资料不多，但这个工具本身就是阿里开源的，团队一直在用。

06 两种Mock方案的区别

这里我整理一下，刚才聊的其实是两种不同的Mock思路：

方案一：独立Mock服务，如Moco、WireMock

• 起一个独立的Mock Server
• 需要被测应用修改配置，把请求地址指向Mock Server
• 优点：独立部署，规则配置灵活
• 缺点：侵入性，需要代码配合改造

方案二：Sidecar代理模式

• 把代理程序跟应用放在同一个Pod/容器里
• 代理程序拦截应用发出的网络请求
• 优点：对代码无侵入，不需要改业务代码
• 缺点：需要改造部署配置，有一定运维成本

ZX的情况是：代码写死了第三方接口地址，开发不愿意改。那方案一就走不通了，只能走方案二。

07 在K8s里怎么落地？

ZX接着问：“那我怎么在K8s里把它跑起来？”

“你先找到应用启动的那个文件，比如Dockerfile。在里面把Sidecar的jar包下载下来，然后加一个启动命令。”

“这个我弄过。”

“那剩下的就是配置问题了。Sidecar启动后，你需要一个方式来配置Mock规则。它本身应该开放了一些HTTP接口，可以远程调用，动态设置规则。”

我翻了翻文档，找到了/save和/update这类接口，还有一个本地Web管理页面。

“你可以把这些接口封装一下，或者直接用它的管理后台。这样自动化用例跑之前，先调一下接口把规则配好，跑完再清理。”

“行，应该能行。”ZX说。

08 我还是忍不住吐槽了写死的代码

聊到这里，虽然方案有了，但我还是觉得那个写死的代码是个隐患。

“你们公司开发把微信接口地址写死在代码里，这很奇怪。大部分项目都会把这些对外域名改成配置的。”

“是啊，我看着那代码也很……”ZX欲言又止。

“你本身就是做这个服务的，改成环境变量很简单。你可以跟他们提一下，推动一下。”

“嗯，我可以跟他们提。”

这就是测试左移的价值——不是被动地去适应烂代码，而是主动推动代码变得更可测。

如果开发愿意把写死的地址改成环境变量，那Mock方案就会简单很多，团队里每个人都能受益。

09 写在最后

这次辅导一共聊了18分钟。从“Mock会影响到别人怎么办”开始，一路聊到K8s的IP变化、Sidecar的部署、代码写死的问题，最后还推动了一下代码改造。

ZX说：“我回去研究一下，上班的时候比较闲。”

“上班比较闲？你们工作还挺好的嘛。”

“没有，就是工资低。”ZX笑着说。

这大概是很多测试同学的现状——拿着一份不算高的工资，却要搞定K8s、Sidecar、接口自动化、代码推动……事儿一样不少。

但好消息是，技术是杠杆。当测试同学把Mock体系搭起来，让整个团队的自动化测试能稳定运行，就从“执行者”变成了“赋能者”。这个能力的提升，远比那一份工资的增长要快。

至于ZX最后能不能跑通？大概率能。因为方向对了，剩下的只是执行。

本文根据霍格沃兹测试开发学社真实私教对话整理，内容已脱敏。