为什么要做测试驱动开发

测试驱动开发（TDD）是有经验的软件工程师用来确保应用状态符合预期的技术。在更传统的应用以及软件工程的整体演进里，测试已经被公认为每一套成功且专业打造的软件系统的一部分。如今，仍然有大量公司认为写测试拖慢开发、提高成本，总体上是浪费时间。希望这篇文章能照出这种说法错得有多离谱。

什么阻碍软件正常工作？

世上没有完美写就的软件，大概也永远不会有。 “bug”这个词最早于 1946 年在哈佛被提出。当时 Grace Hopper 让一个故事流传开来：一只飞蛾在早期机电计算机里搞出了问题。Hopper 当时在哈佛做 Mark II/III 计算机系统，他发现一只飞蛾被卡在继电器里造成了故障。

把飞蛾取出后，Hopper 在笔记里写下：“First actual case of bug being found（首次真正发现 bug 的实例）。”自此“bug”一词被用来表示计算机系统中的意外行为。一个系统有 bug 的概率？100/100 个项目。如果我雇用地球上最好的工程师，系统有 bug 的概率？100/100 个项目。所以雇更好的工程师并不能解决问题。它当然会让 bug 变少，但不会让 bug 消失。这就是为什么要写测试，因为没有无错的软件。

Grace Hopper 的 bug（1946）

TDD：降低成本，提升质量

在测试驱动开发（TDD）里，工程师在实现逻辑之前先写测试。不展开技术细节，这导致下列结果： 如果做得好，它确保没有未经测试的代码被推到仓库里，因为你已经先写了一份专门的测试。这能解决前面讨论的 bug 问题吗？很遗憾，不能。但它是我们手上最好的技术之一，用来创造久经考验、有韧性的软件。

"尽早验证假设，把后面昂贵的错误降到最低。"

那 Web3 有什么不同？ 在 Web3 开发中，安全是最高优先级。智能合约常常管理大量加密货币和其他有价值的数字资产。任何这些合约里的漏洞都会带来重大资金损失。TDD 通过促进持续测试和早期识别潜在问题，扮演了关键的安全角色。

在开发周期早期捕捉到安全缺陷，TDD 有助于防御那些会损害去中心化应用完整性的利用与攻击。测试让工程师调整代码库并立即得到反馈。如果测试写得到位，任何可能导致 bug 的代码改动都会被测试抓到并上报。

重要的是，上面这些用普通测试也能做到。所谓普通测试，就是想到“现在写一个测试”才写。许多工程师走这条路：“我现在写代码，等有时间再补测试。”从某种程度上说，这没问题。比一行测试都不写好得多！但它永远达不到 TDD 的韧性级别，因为它根本错过了重点。 我乐意重复一遍：“没有未经测试的代码会进生产”。这才是纯粹 TDD 所确保的。

完全不写测试最终会反噬你

沉默的杀手：技术债

我还欠你一个解释：为什么不写测试会让工程和维护成本爆炸。关键词是技术债。软件总会有 bug。它存在越久、越大，产生的 bug 就越多。这不是我用来强调本节而编出来的，是众所周知的事实。 因此，如果没有任何对策来发现和消除这些 bug，它们会一直留下来并影响后续加进代码库的代码，反复影响。 我们给软件加的功能越多，问题就越大。终于有一天，这座塔倒了，你站在一份已经无法控制的代码库前。

导致项目整体或部分被推倒重建。

设想一个小镇决定快速搭一座桥连接河两岸。工程师们在赶工中跳过了一些安全检查，用了更次的材料。一开始桥运行良好，大家对速度赞不绝口。时间过去，越来越多车开始走这座桥。小裂缝出现了，但被忽略了，因为桥还立着。每辆新车都增加压力，让裂缝变大。一天，一辆超重卡车开过桥，桥塌了，造成巨大停摆。

这正是软件中的技术债。早期的捷径和未经测试的代码制造隐藏问题。随着新功能不断加入，这些问题增长，直到系统变脆。最终一个看似微小的改动就能引发灾难性故障，就像超载卡车之于那座桥。如果没有测试来尽早捕捉并修复问题，软件就变得不可持续，成本飙升，最终崩塌。

建议 1： 招聘开发者时，用简单问题测试他们在测试方面的熟练度：

→ 你写测试的经验如何？
→ 你在本项目里偏好哪种测试，为什么？
→ 我们真的需要写测试吗？

建议 2：如果他们对测试不在意，他们对你的产品也不会在意。

听起来很狠，但这是真的。

没有测试，你的项目终将死去，这一点毫无疑问。