Unit testing 为什么我们要编写测试用例？

所以我知道你可能会说，这不是一个好问题，简单的搜索可以给我答案，但这不是真的。我读了很多关于测试及其重要性的书。我知道编写测试用例有助于在编程时发现潜在的错误。而且，当你读这些书时，它们都只是在重复相同的抽象定义。但是在写了大量的测试用例之后，我得出了这样的结论：它既不能防止潜在的错误，也不能提高产品质量

因此，假设我们有一个测试用例，如下所示：

Assert.IsTrue(divideNumbers(4,3) == 1);
Assert.IsTrue(divideNumbers(4,2) == 2);
Assert.AreEqual(divideNumbers(8, 4), 2);
Assert.That(divide(10,2), Eq(5))

所以，在编写测试用例时，通常我们试图证明一系列非常基本的问题的真实性，比如两个等式是真的吗？此功能的结果是否等于所需的结果？他们平等吗？它失败了吗？对象是指定类的实例吗

我在很多软件开发团队工作过。几乎在所有的时间和团队中，在编写了一些测试用例之后，我们都会遇到这样一种情况：我们看到断言类的函数不能帮助我们，因为它们是非常基本的，而错误通常会在特定的情况下出现，而这些情况与是否为真、是否相等、是否为空无关

---

那么，为什么真的要编写测试用例呢？为什么我们真的需要它们，以及它们如何帮助我们提高产品质量和减少潜在错误

编写单元测试的原因是组合学。将函数想象成图中的节点，函数之间的调用想象成边。

main

是源节点，终止程序的函数是目标节点。程序可以显示的不同行为的数量等于从源节点到任何目标节点的路径数量。节点和边的数量是指数级的。这意味着，不可能测试您的程序可能表现出的所有不同行为。这就是单元测试的用武之地。每个单元测试测试图形的一个节点（使用特定输入调用函数产生预期输出）或一条边（使用特定输入调用函数生成对相邻函数的函数调用）。然后所需的测试数量仅为

O（|V|+|E|）

这有一个限制，即您无法捕获仅在执行特定路径时表示的bug，而在调用单个函数时不表示这些bug。这就是为什么写自足函数时尽可能少地与其他函数耦合很重要的原因

几乎在所有的时间和团队中，在编写了一些测试用例之后，我们都会遇到这样一种情况，即我们看到Assert类的函数不能帮助我们，因为它们是非常基本的，而错误通常会在特定的情况下出现，而这些情况与是否为真、是否为相等、是否为空无关

这是你自己说的。基本的

断言

通常用于单元测试或简单测试或任何您称之为的测试。也就是说，它们通常用于验证一些简单方法的输出，或者确保变量保持在允许的最小值和最大值之间。如果某个web服务结果包含所需的数据，则不能期望通过断言来验证

这些错误通常在特定的情况下出现，而这些情况与是否为真、是否相等、是否为空无关

健康的测试与代码的模块化直接相关。在正确设计的代码中，测试会容易得多，并且您不会试图找到测试特定代码部分的变通方法。也许你所经历的可以用更好的软件设计方法来解决

那么，为什么真的要编写测试用例呢？为什么我们真的需要它们，以及它们如何帮助我们提高产品质量和减少潜在错误

---

你不必测试你的程序。有这么多的代码不用一次测试就可以编写，它们也可以完成这项工作。尽管经过适当测试的代码会让人们感到高兴，但很多测试书籍、教程等都提到了这一点。

当您编写没有测试的代码时，您会怎么做？在运行整个应用程序的几乎每次更改之后，您都要等到它启动，然后转到刚刚更改的页面，输入一些数据，然后按下按钮并进行检查。。。如果答案正确，弹出窗口是否出现，邮件是否发送等等。你做测试。但你只需要手动操作。每次改变后你都要重复这些测试。如果你不重复这些错误，那么你会在生产中发现错误，你必须在压力下迅速纠正它们，你必须再次检查你是否正确地修复了它们。而且你必须手动操作

因此，与其在每次更改后重复，不如编写有价值的测试，快速运行它们，修复bug，然后早点回家

---

这样或那样你做测试。一开始，自动测试似乎需要更多的时间，因为您必须编写更多的代码

如果您的测试用例没有用处，请编写更好的测试！您是否在问为什么要编写单元测试而不是集成测试，或者为什么要编写测试？如何编写？什么是好的测试用例？我在问，为什么我们要写这个测试？我昨天也这么想。测试并没有像检查代码中的内联内容那样有用。也许很混乱，但实际上做了一些事情，而不是假装专业。