测试是为了未来

想象一下：你刚刚为一个新功能编写了一些代码。你正在编写一些单元测试。在编写测试的过程中，你开始陷入一种生存危机。“我为什么要写这些测试？”你问自己。“我已经手动验证过我的代码可以正常工作，甚至还让另一个开发人员亲自测试了一遍。这还有什么意义呢？”

答案在于一个关键的认识：你的测试是为了未来。

当然，它们现在也适用，可以帮助你发现在开发新功能时可能忘记的一些边缘情况。但测试主要针对的是那些在未来几个月甚至几年内会继续使用你的代码的人。

让我们来探究一下这是如何真实的。

文档

测试可作为某个功能应如何运行的文档。

测试本质上是以代码形式编写的产品需求。后续使用此功能的开发人员可能会对代码的意图或某些场景的处理方式产生疑问。

开发人员无需深入研究旧的 JIRA 工单或托管在其他地方的可能过时的文档，而是可以直接在 IDE 中跳转到测试套件。通过查看测试用例，他们可以很好地了解该功能的工作原理。

测试可以帮助您在开发新功能时避免代码库的回归。

虽然这些新功能可能看起来与某些现有代码无关，但两者之间可能存在某种你忽略的联系。一套完善的测试套件能够发现那些你无意中对现有代码造成负面影响的地方。

如果没有测试，您就无法确定所编写的新代码是否能与旧代码很好地兼容，除非进行大量（且繁琐）的手动测试。

编写测试的最令人信服的理由以及它们对未来的意义在于它们允许您满怀信心地进行重构。

我敢肯定，你曾经在某个团队维护的大型遗留应用程序工作过。这个遗留应用程序中隐藏着一些至关重要的东西。也许是你的支付处理业务逻辑。也许是你的身份验证码。

不管它是什么，它对于应用程序的核心功能至关重要，但每个人都不敢碰它。它很老旧，看起来运行正常，但现在却变成了一堆乱七八糟的意大利面条式代码，再也没人真正理解了。

为什么大家都不敢使用它？因为它没有任何测试！这意味着你修改的每一行代码都有可能在你不知情的情况下破坏某些功能。这意味着你对这个功能做的每一个小改动都需要经过大量的手动测试。这意味着当你点击“提交”按钮合并代码时，你会非常紧张，双手合十祈祷。

现在，想象一下，同样的核心功能，但有一个完善的测试套件，能够充分覆盖代码。当需要重构代码时，你就可以充满信心地去做。为什么？因为你会知道是否出了什么问题。如果现在所有测试都通过了，你做了一些修改，但又出现了一些问题，那么很明显，有些地方还不够完善。

但这并不麻烦，因为您在将这些新更改发布到生产之前就已经发现了错误，并且能够找到根本原因并确保您的重构这次正常运行。

测试是为了未来。它们提供文档，帮助你避免回归，并让你充满信心地进行重构。

PS：如果您想了解更多信息，请查看我关于测试驱动开发的文章。