单元测试：为什么有必要[关闭]

Question

您好，我将尝试解释我对单元测试的实际理解以及为什么我无法掌握它的实用性。

即使我尽我所能理解 TTD、单元测试、集成测试等的概念。从我阅读的大多数文章中，我解释了如何去做（用一个简单的例子或框架），有时如何在某些情况下，测试为他们节省了数小时的调试时间。我有两个问题：

第一：方法

让我们用一个基本的例子来解释如何进行单元测试：

您想测试您的 add 函数是否按预期工作，因此在您的测试文件中，您编写一个具有预期输出的函数模拟让我们这样说：

import add from ./calculate
function myTestingFunction() {
    add(3, 5)
    expectedOutput(8)
}

好的，所以你解释一下怎么做，但没有解释为什么......即使这样，我也有很多问题：

• 您正在用另一个函数测试一个函数...那为什么要停在那里并测试您刚刚创建的函数？
• 它是代码，它有算法，所以如何确保它是正确编写的 ?
• 为什么要停止预期的输出？为什么不测试 输入是正确的类型，因为如果我给我的 添加函数它会失败，不是吗？

而且每篇文章基本上都是这样。因此，考虑到这些问题，我什至找不到尝试这种方法的动机：这似乎不合逻辑。

第二：测试既省时又省钱

假设现在我想以相同的方式测试 Divide 函数，并为输入 9 和 3 编写预期输出 3。

好的，所以我编写了与之前解释的相同的函数。 但是，如果用户试图除以 0，那么他在逻辑上就会出现一个严重的错误……这个测试不包括这种情况，我正在编写测试以确保我的代码运行良好（或者至少给出正确的输出）。

在现实生活中我现在看到两种情况：

• 我已经向我的客户解释说我会花更多的时间来编写代码（所以他会付给我更多的钱），但结果他会确保最终他的功能是防弹的。在这里我要对他说“嗯......对不起，我没有考虑这个用例”“所以我付给你更多，因为你说你编写的测试将确保一个没有错误的应用程序......但是不是吗？现在我要付钱给你调试？” （所以没有节省时间和金钱，并且与我的客户关系不好）
• 我已按照我和我的客户解释和理解的方式对功能进行了编码。出现了我们不知道的新用例。 ' 没问题：我拉一个分支来修复错误，修复错误，推送修补程序，如果需要，记录特殊用例。现在，如果我将来遇到类似的问题，我将已经准备好算法，因为我遇到了这个问题（为我和我的客户节省了时间和金钱，并且总体上更好的关系）

我不知道我是否清楚我的心态，但我已经和我的许多同事讨论过这些元素（有些甚至比我有更多的实践经验或更好的学校学位）并且他们有关于测试的问题与我相同：即使我们真的想了解这个主题并在需要时实施一种好的工作方式，但到目前为止，这似乎是某种知识上的骄傲。

Answer 1

根据我的个人经验，答案归结为一个词 -> 信心。

一段时间后或当代码库变得更大并且您不再熟悉代码时，如果没有足够的单元测试来确保预期的功能，那么轻松更改代码就会变得有问题。如果在更改领域有良好的单元测试覆盖率，那么我更有信心我所做的任何更改都不会引入任何意外的副作用（阅读：此处的错误）。

有意义吗？