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

Question

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

Answer 1

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

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

1. 它没有规模。如果您有一个非平凡的应用程序，您将花费数小时作为用户进行每次发布测试。

2. 这是一种浪费。你最终会因为自己的偏见一遍又一遍地运行相同的测试。您将始终测试您最了解的功能，并最终进入例行程序。“我点击这个，然后那个，然后这个......并且应用程序很好！” 如果您总是测试相同的东西，那只是浪费时间。

3. 你得不到保障。与 (2) 类似……您认为您触及了应用程序的每个部分，但您不会。

4. 很难重建状态。您可能会遇到一个错误，该错误仅在用户单击页面 A，然后是 B，然后是 A，然后是 D，​​然后是 C，然后是 A。之后，系统处于有趣的状态。你永远不会通过随意的点击来重现它。

5. 即使你发现了一个错误，你也只是碰到了冰山一角。尝试找出该 UI 功能下的哪个方法实际上是问题所在，玩得开心。

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