接着上一条,简单补充下测试跑得慢、CI 资源消耗大的问题。评论里不少朋友问到了, @yetone 也提到了。Vibe coding 时,代码产出快了,这个问题就更明显了。
我负责的研发团队,一天上线 50 次,一天至少要跑 300 轮测试。在测试写对的基础上,怎么跑得更快、更省,可以尝试从这几个地方处理。
做精准测试(Vitest 自带的比较糙,效果有限)。记录每个测试实际经过的代码,源码变更后,就能反查大概会影响哪些测试。可以做到文件级,也可以做到函数级,我个人选择文件级。
函数级能少跑一些测试,但采集、分析和维护依赖成本也不低。文件级会多选一些测试,不过实现更简单,我更看重整体能省多少时间。当然配置、依赖、初始化这些变化要单独处理。
此外还可以做测试分级。
前面按 BDD 的方式描述业务场景,到这里就比较容易分清哪些是核心业务路径(写好测试是一切的基础哈)。高频 CI 跑核心路径、新增和修改的测试。其余测试,有代码变更就每小时集中跑一轮。
这样做,部分非核心问题可能会晚一点被发现,能接受多长时间,要看自己的业务。
还有个容易忽略的地方是 runner。不同测试集对 CPU、内存、IO 的需求不一样,要看机器的实际负载,分配合适的机器,控制好并发度。并发开大了,不一定更快。
我们也用了本地 runner,在自己配置好的机器上跑。在我们的使用场景里,成本比 GitHub 托管 runner 低不少。
好了,测试相关的分享先告一段落,希望有一点点帮助。接下来会逐步聊聊,为什么只靠测试还不足以保证软件质量,以及 AI 写的代码该怎么 review、重点看什么。
两篇精准测试的论文放评论区,感兴趣可以看看