一款业余游戏有 1000 多个测试——是浪费吗？

我们的项目现在有远超一千个自动化测试：服务器端约 990 个，Unity 客户端约 120 个。对一个家庭项目来说，这听起来有点小题大做。恰恰相反——原因如下。

测试是我们的第二位开发者。作为一个独立项目，没有人会在代码评审时说：“等等，这会搞坏合成。”测试就是这位同事。每一个游戏机制——配方、氧气、饥饿、生物行为、世界密码——都有随每次改动运行的测试。无所畏惧地重构，才是真正的收获。

快到不让人烦。要花一刻钟的测试，没有人会去跑。所以我们的 CI 关卡分两个阶段：拉取请求检查用快速测试，三分钟多一点就跑完；完整而较慢的测试集随后再运行。这样既让开发循环保持轻快，又不损失覆盖率。

测试 Unity 是另一个话题。客户端逻辑很难在运行中的引擎里测试。我们的办法是：客户端的核心逻辑放在一个独立的库里，不依赖 Unity 运行——我们像测试普通代码一样无头地测试它。只有真正需要引擎的部分，才作为 EditMode/PlayMode 测试运行。

警告就是错误。我们的 CI 用“warnaserror”构建：每一条编译器警告都会让构建失败。听起来很较真，但它避免了那个“警告坟场”——那条真正重要的警告，最终会淹没在里面。

坦率的结论：写测试大概要花五分之一的开发时间。但每一个修好的功能都会一直是好的——而对于一个靠下班后的晚上才活起来的项目来说，没有什么比确信周末的功能没有搞坏周二的功能更有价值了。