“这些到底什么时候才能写完……”连实现一个功能都时间紧张，如果还要求写测试代码，说实话只想先叹口气。
先说结论，写测试代码的真正原因是“保护未来的自己”。现在多花10分钟，是为了避免3个月后凌晨突然爆发的故障。
为什么要写测试代码？
最大的原因是，修改代码不再令人害怕。
代码不是写完一次就结束了。你会不断修改代码并添加功能。
没有测试时，每改一行代码都会感到不安。“改了这里，其他地方不会出问题吗？”
有测试的话，修改后运行一次就能确认。绿色表示安心，红色则会立即告诉你哪里坏了。
这叫作“回归测试”，也就是捕获原本正常、后来再次出问题的部分。
即使麻烦也要写测试代码的真正原因
说实话，测试代码刚开始会让人觉得吃亏。毕竟它不会增加看得见的功能。
但项目越大，情况就越不一样。
功能增加到30个、50个后，手动逐一确认是不可能的。每改一处，也不可能把所有地方都点一遍。
这时有了测试，只需一行命令，就能在几秒内验证几十个案例。
第二个原因是，测试代码本身就会成为“文档”。
看编写良好的测试代码，就能一眼看出这个函数对什么输入产生什么结果。
注释过时后可能会说谎，但测试会被执行，所以不会说谎。
来看一个简单的例子：计算折扣金额的函数测试。
// 1一万韩元 10% 折扣 → 9应为一千韩元
@Test func 应用_10折扣_百分比() {
let result = applyDiscount(10000, rate: 0.1)
#expect(result == 9000)
}只看这个测试，就能立刻理解applyDiscount这个函数的作用。
如何开始写测试代码？
一开始就想测试所有内容，很快会筋疲力尽并放弃。
我建议这样开始。
- 先从金额计算、登录等“出问题就麻烦了”的核心逻辑开始
- 条件分支很多、容易混淆的函数
- 曾经出现过 bug 的地方（用于防止复发）
相反，简单的界面代码和经常变化的部分可以之后再做。
目标不是把所有内容都测试到100%，关键是权衡成本与收益。
常见问题
Q. 写测试会让开发变慢吗？
A. 一开始会变慢。但从项目中期开始反而会更快，因为查找和修复 bug 的时间会大幅减少。
Q. 测试覆盖率多少比较好？
A. 不必执着于数字。70～80%就足够，更重要的是关键逻辑是否得到了覆盖。
测试代码不是炫耀能力，而是为未来的自己和同事准备的安全网。
现在就给今天写的一个函数添加一个测试吧。感受过那盏小小绿灯带来的安心后，你就会亲身体会到为什么大家都让你写测试。