Testing 为什么要编写单元测试方法？

我发现很多人浪费了很多时间来编写数百行代码来测试应用程序。有时更改应用程序架构只是为了使测试方法更易于编写。我们为什么不用计算机来测试方法呢。我的意思是，我们的行为就像用户一样，我们试图提供不同的输入，看看结果是否符合我们的预期

我会尝试回答更多细节。我认为争论的焦点是为什么要编写大量的单元测试，而不是仅仅点击应用程序来查看它是否如预期的那样工作。其逻辑是，与编写数千行代码进行测试相比，单击几个按钮所需的时间更少

我曾在几家拥有面向公众网站的公司工作过，我可以告诉你，“点击周围”测试方法非常糟糕。原因:

它无法缩放。如果您有一个非常重要的应用程序，那么您将作为用户花费数小时进行每个版本的测试

这是浪费。你最终会因为自己的偏见而一次又一次地通过同样的测试。你总是会测试你最熟悉的功能，最终你会陷入常规。“我点击这个，然后点击那个，然后点击这个……应用程序很好！”如果你总是测试同样的东西，那只是浪费时间

你得不到保险。类似于（2）。。。你认为你已经击中了应用程序的每一个部分，但你不会

很难重新创建状态。您可能有一个bug，只有在用户单击页面a、B、a、D、C、a之后才会出现。在所有这些之后，单击系统处于一种有趣的状态。你永远不会用随意的点击来重新制作它

即使你发现了一只虫子，你也只是触及了冰山一角。试着找出UI功能下的哪个方法才是真正的问题所在

---

我可以继续下去，但是单元测试解决了所有这些问题。甚至还有一些工具可以向您展示测试的代码覆盖率

网上有大量关于测试驱动设计和测试的信息。你的问题不够具体，因为它很具体，请再读一遍，每个人都以某种方式（测试方法）进行测试，我建议另一种方式（使用），告诉我谁是最好的，为什么？简单的答案是成本。运行1000个自动测试几乎不需要任何成本，用户的成本要高出很多倍。不是用户，而是你作为一个程序员，你的行为就像用户，你的测试，我认为比写几百行更少！