不写测试
「我们追求速度，所以不写测试」——这种说法我见过很多次了。
以前的我模模糊糊地觉得，也许真有这种需要吧。但随着时间推移，我的疑虑越来越深。
不写测试，开发速度就能提高？真的吗？
现在我完全无法理解。甚至会忍不住皱眉。让我来想想，自己为什么会变成这样。
不写测试真的更快吗？
不写测试，代码量确实会减少。
简单推导一下：「不写测试 = 少写代码 = 更快」。
但现实并没有这么简单。
自动测试是手动测试的替代品。
搭建前置条件、操作浏览器、确认结果——这是一项极其耗时的繁琐工作。
不仅如此，这还会影响 Code Review。Reviewer 如果不亲自启动环境跑一遍，根本无法确定 PR 是否真的能正常工作。
而有了测试代码，很多时候只需要 Review 测试本身就够了。边界情况处理得是否妥当，一目了然。
自动测试节省的，不只是一个人手动测试的时间。
所谓的收支平衡点
重构相关的讨论中，经常会提到「收支平衡点」的概念。
测试也是如此吗？
我不这么认为。
不存在什么收支平衡点。从头到尾，写测试都比不写测试更快——这是我的观点。
- 省去多人重复验证的时间
- 避免回归 bug 以及随之而来的排查和修复成本
光是这两点，就足以断言写测试更快。
「为了速度」的真相
以上这些，对于有一定经验的工程师来说，应该是不言自明的道理。
那为什么「为了速度」这种说法还是随处可见呢？
负责人经验不足
决定是否写测试的人，可能根本没有真正理解测试的价值。
他们可能从未经历过测试发挥作用的项目，对测试的印象停留在负面。
这情有可原。但说到底，这是经验不足导致的判断失误。
团队能力不足
在创业公司中很常见：招不到经验丰富的人，团队只能由能力较弱的成员组成。
团队缺乏编写测试的技能和 know-how，导致写测试的成本急剧上升。
在这种情况下，不写测试确实可能带来速度上的提升。于是「追求速度所以不写测试」就变成了一个成立的命题。
现实中，这种情况恐怕是最多的。
根本没想过
「项目初期不写测试以追求速度，等上了轨道再补」——这是一个常见的说法。
问题是，有人会照字面意思照单全收。
这种说法通常针对的是原型开发。在那个语境下它可能是对的，但如果脱离语境、按字面意思理解，就会导致错误的判断。
这和负责人经验不足有重叠之处，但这种不假思索的态度，同样会催生出「不写测试」的决定。
真的可以不写测试的场景
其实确实存在不需要写测试的情况。
原型开发和一次性脚本
不需要持续开发和维护，或者复杂度很低的场景下，不写测试确实可能加快速度。
出了回归 bug，发现了再修就行——这种取舍是可以接受的。
有专职测试人员
开发团队和测试团队明确分工，动作确认和回归检测的成本不需要开发团队承担。
这相当于用人力替代了测试代码的功能。在自动化测试非常困难的游戏开发领域，这种模式比较常见。
不过，在这些情况下，人们不会说「为了速度才不写测试」。他们只是「判断不写更好」而已。
面子问题
说到底，不写测试的理由，从来都不是「为了速度」。
不是「不写」，而是「写不了」。不是主动选择，而是没得选，或者选错了。
不愿承认能力不足或判断失误，于是用「为了速度」来给自己找台阶下——保住面子。
想到这里，我的疑惑终于解开了。
