所以我知道你可能会说，这不是一个好问题，简单的搜索可以给我答案，但事实并非如此。我已经阅读了很多关于测试及其重要性的文章。我知道编写测试用例有助于在编程时发现潜在的错误。此外，当您阅读书籍时，他们都只是重复相同的抽象定义。但在编写了大量测试用例之后，我得出了这样的结论：既没有防止潜在的错误也没有提高产品质量。
因此，想象一下我们在一系列函数中有一个测试用例：
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))
因此，在编写测试用例时，通常我们会尝试断言一堆非常基本的问题的真实性，例如两个方程式是否正确？该函数的结果是否等于期望的结果？他们是平等的吗？它失败了吗？对象是指定类的实例吗？，.......
我曾在很多软件开发团队工作过。几乎在所有时间和所有团队中，在编写一些测试用例后，我们遇到一种情况，我们看到 Assert Class 的功能无法帮助我们，因为它们非常基本，而错误通常会引发在特定的情况下，不是真实的，平等的，不是空的，......
那么，为什么要真正编写测试用例呢？为什么我们真的需要它们以及它们如何帮助我们提高产品质量并减少潜在错误？
答案 0 :(得分：0)
编写单元测试的原因是组合测试。将您的函数设想为图形中的节点，并在函数之间调用边缘。 main是源节点，终止程序的函数是目标节点。程序可以显示的不同行为的数量等于从源节点到任何目标节点的路径数。这是节点和边数的指数。这意味着测试您的程序可以展示的所有不同行为是不可行的。这是单元测试的用武之地。每个单元测试测试一个节点（调用具有特定输入的函数产生预期输出）或一个边缘（调用具有特定输入的函数生成对相邻函数的函数调用） 。然后所需的测试数量仅为O(|V|+|E|)。
这有一个限制，即您无法捕获仅在执行特定路径时表达的错误，并且在调用单个函数时不表达错误。这个限制就是为什么用尽可能少的耦合编写自包含函数与其他函数一起很重要的原因。
答案 1 :(得分：0)
几乎在所有时间和所有团队中，在编写一些测试用例后，我们遇到一种情况，我们发现Assert Class的功能无法帮助我们，因为它们是非常基本的而错误通常在特定情况下引起，这些情况不是真实的，平等的，不是空的，......
你自己说过了。基本Asserts通常用于单元测试或简单测试或任何你称之为的测试。也就是说，它们通常用于验证某个简单方法的输出，或确保那里的变量保持在最小和最大允许值之间。您不能指望Assert验证某些Web服务结果是否包含您想要的数据。
错误通常在特定情况下引起，这些情况不是真实的，是平等的，不是空的
健康测试与代码的模块化直接相关。在设计合理的代码中，测试会更容易，您最终不会试图找到测试特定代码部分的变通方法。也许您正在经历的事情可以通过更好的软件设计方法来解决。
那么，为什么要真正编写测试用例呢？为什么我们真的需要它们以及它们如何帮助我们提高产品质量并减少潜在的错误？
您无需测试您的程序。没有一次测试就写了很多代码，他们也可以完成这项工作。虽然经过适当测试的代码让人们感到高兴，因为很多测试书籍，教程等中提到了明显的原因。
答案 2 :(得分：0)
在没有测试的情况下编写代码时你会怎么做？几乎每次更改后你运行整个应用程序，你等到它开始，你转到你刚刚改变的页面，你输入一些数据，你按下按钮然后检查......如果答案是正确的，如果弹出窗口出现，邮件是否已发送等等。你做测试。但你只需手动完成。并且在每次更改后重复所有这些测试。如果你不重复它们，你会发现生产中的错误，你将不得不在压力下迅速纠正它们，你将不得不再次检查你是否正确修复它们。你必须手动完成......
所以不要在每次更改后重复它，只需编写VALUABLE测试，快速运行它们，修复bug并提前回家。
这样或那样你做的测试。在开始时，似乎自动测试需要更多时间，因为你必须编写更多代码