```html

测试吧

上周三凌晨两点，我盯着终端里一行红色的测试 FAIL，终于把那个困扰了团队三天的测试支付回调 bug 钉死在了单元测试里。问题出在一个边界条件：当订单金额为 0 且优惠券刚好抵扣完时，测试回调签名校验会跳过。测试手动测试根本没人会去点那个“0元支付”的测试按钮，但自动化测试用一个 mock 请求就把它揪出来了。测试这就是测试测试吧——一个你不主动去建，迟早会以更昂贵的测试方式找上门的地方。

很多人把测试当成开发完之后的测试“附加题”。我见过不少项目，测试代码仓库里 test/ 目录空空如也，测试或者只有几个象征性的测试 assert(true)。问起来就是测试“业务太忙，先上线再说”。测试结果呢？上线当天晚上十一点，运维群里开始刷屏，你一边回滚一边手动改数据库，心里骂娘。这种场景我经历过至少三次，每次都是因为某个看似无害的改动——改了个日期格式、换了个排序字段——把下游逻辑炸得稀碎。

测试吧，它不是一个“阶段”，而是一种做事习惯。我现在的习惯是：写任何新函数之前，先想一下它的输入输出边界。比如一个计算折扣的函数，别急着写 if (user.isVip) return price * 0.8。先开个测试文件，把 price=0、price=负数、user=null、折扣叠加 这些情况全列出来。写测试用例的过程，其实就是逼自己把需求想清楚的过程。很多时候，测试还没跑，我就发现产品文档里漏掉了一个场景。

上面这个补零问题，就是典型的“手动测试盲区”。你手动测的时候，正好是 10 号以后，看不出问题。但到了月初 1 号，前端展示就变成了 2025-1-5，用户截图发到客服群里，你还得紧急发个 hotfix。如果一开始就写了测试用例，跑一遍就发现了。成本差多少？写测试 30 秒，线上修复 2 小时，外加一顿宵夜安抚运维兄弟。

也有人走另一个极端：追求 100% 覆盖率，每个 getter/setter 都写测试。这纯粹是给自己找罪受。我的判断标准很简单：这段代码如果错了，会不会让我半夜爬起来修？ 会，那就写测试。不会，那就先放着。比如一个纯展示用的静态文案组件，测试它干嘛？但如果是支付金额计算、权限校验、库存扣减，那必须往死里测。边界值、异常流、并发场景，一个都不能少。

还有一个观察：测试写得好的人，代码结构通常不会太差。因为你要让代码可测，就得解耦、就得依赖注入、就得把纯逻辑和副作用分开。反过来，那些一写测试就发现“根本没法测”的代码，往往就是一团乱麻。所以有时候我把写测试当成代码 review 的替代品——如果一个模块我写不出测试，那说明它的设计有问题，先重构再说。

“测试不是证明你对，而是找出你错。”

这话谁说的我忘了，但意思很直白。单元测试、集成测试、端到端测试，各有各的用处。单元测试跑得快，给你即时反馈；集成测试验证模块之间有没有互相坑；端到端测试最慢，但能模拟真实用户路径。我一般把 70% 的精力花在单元测试上，20% 给集成，剩下 10% 给关键的端到端流程。别倒过来，否则你的 CI 流水线会慢得让你想砸键盘。

最后说个工具层面的小事。别纠结用 Jest 还是 Vitest，用 JUnit 还是 TestNG。选一个你团队最顺手的，然后坚持写下去。我见过太多人花一周时间对比测试框架，结果一行测试代码没写。工具是次要的，习惯才是核心。就像跑步，你穿什么鞋不重要，重要的是你每天出门跑那三公里。

测试吧，它不会让你变成更好的开发者，但会让你变成一个更少被骂的开发者。而在这个行业里，少被骂已经是一种了不起的成就了。

—— 写于一个刚被测试拯救的深夜