我：“我已经测试过了，而且它可以工作，为什么我还要写测试？”

我见过唯一有效的论点是

我在大学期间就开始用 PHP 和 JavaScript 编程了。那时，我对任何软件测试都一无所知。确保代码正常运行的唯一方法是在浏览器中手动测试。我猜想，如果是软件更复杂的大公司，肯定会有十几个人排队在软件界面前进行手动测试。

我记得当时甚至有一个电子表格，上面写满了一排排的用例，还有在发布前需要勾选的复选框。即便如此，bug仍然会出现。代码发布时，我手动测试了几个我知道的用例，但我根本无法测试应用程序允许的所有可能用例。这是我开发生涯中最适得其反的时刻之一。

然后我发现了软件测试。这真是个福音。它系统地覆盖用例、维护应用程序稳定性，以及通过持续集成自动完成这些工作的方式，真的让我惊叹不已。我不再需要数百万行的电子表格，可以更自信地交付代码。

在我看来，即使是现在，测试的概念对某些人来说仍然难以接受。我能理解，这主要是因为害怕改变；试图让人们走出“我写的代码，它能用”的舒适区并非易事。我记得一些反对测试的论点：

• “我对我的代码很有信心，它不会被破坏。”
• “我测试了所有用例，它们都很好。”
• “你可以检查我的代码，指出其中的缺陷，如果没有缺陷，就可以了。”

所有这些争论都源于开发人员的“人为”因素：他们对代码的信心、他们的手动测试技能以及他们编写的无瑕疵代码。这些因素非常重要，不容忽视。而软件测试则涵盖了“人为”因素失效的情况。人无完人，难免会犯错，而我们会从经验中吸取教训。当你编写代码，甚至当其他人审查代码时，如果某些用例/缺陷被忽略，测试或许能够指出这一点。

这不仅仅是为了维护代码的稳定性和质量。测试定义了代码的规范。我刚才有点笨，但我突然想到为什么测试一开始被称为“规范”。在编写测试时，从一开始就要明确代码能做什么和不能做什么。最近，我甚至养成了一个习惯，当我在某个库的 API/演示页面找不到它时，我会浏览它的测试文件夹来查找它的功能，这确实很有帮助。

即使已经列出了所有关于测试的利好，但让人们参与进来肯定是另一个问题。我能理解为什么人们仍然把测试当作“能让我合并 PR 的东西”。有些人可能仍然会说：“这个功能可以运行，而且我已经测试过了，我们可以先合并，我稍后再写测试。” 其他人会抱怨“就因为我改了一行代码，很多测试就失败了”。

在我看来，他们忽略了全局。如果你修改了代码，当然必须通过所有测试，因为你要确保代码仍然符合代码规范（测试）。如果你添加了新代码，也必须添加测试，因为你在为软件添加新的规范。如果你发布没有测试的代码，那就意味着你发布的代码没有规范；没有任何东西可以确定哪些可以行，哪些不行，包括bug。

大多数开源代码库都非常重视测试，这是有原因的：因为他们非常重视代码的稳定性。一个 bug 就可能危及很多人，包括开发者和用户。构建失败或没有测试的 PR 甚至不会被审核。我想说，这与我们自己的（也许是营利性的？）项目应该没什么区别。说服客户/利益相关者测试的重要性可能很难，但至少对开发者来说不应该那么难。

本文可能不适用于你。我知道有很多实践将测试集成到他们的工作流程中（例如敏捷），而且很多公司已经这样做了。但是，如果它确实适用于你，我希望本文能提供另一种视角来解释测试是什么以及它为什么重要，也许你最终可以摆脱那个充斥着复选框的巨型电子表格。

一如往常，感谢您阅读我的文章！

封面图片由Glenn Carstens-Peters在Unsplash上拍摄。