什么时候应该停止单元测试

Question

我经常可以识别出很多封装好且易于单元测试的区域，但我也发现很多代码在单元测试中似乎并不能正常工作 - 通常是数据访问和用户界面。无论我尝试使用哪种单元测试“技术”，我都倾向于发现在这些地方创建功能单元测试不仅需要付出很多努力，而且这些测试往往非常脆弱，并且不会真正测试。

您在什么时候停下来并决定单位测试的好处不值得花费？

Answer 1

当你通过做其他事情来提供更好的价值时。

Answer 2

我倾向于仅测试模型和数据持久性。 测试模型是强制性的。 UI（桌面应用程序，webapps，命令行界面等）很难测试，因此我只在极少的情况下为它编写测试。

Answer 3

通常我只测试模型和控制器。单元测试难以应用于UI，通常我更喜欢手动测试应用程序。

如果创建这些测试的成本比每次可能有回归的手动测试花费的时间多，那么测试就没用了（很容易说，但不能评估......）。

Answer 4

如果您需要削减测试，请切断集成或端到端测试。谷歌的Misko Hevery解释得非常好here。

  

“单元测试为您提供更多帮助   你的责任“

是他文章中最好的引用。

除此之外，如果你有适当的代码覆盖率并处理代码的一些边缘情况，那么它是停止单元测试的好时机。

Answer 5

如果您可以访问某些实时数据，则可以将其用于单元测试。你也可以使用数据生成器和随机数据。单元测试只能给你一定程度的信心，它将来不会产生问题。如果您对测试有信心，可以停止单元测试

Answer 6

我喜欢这个问题的标题。除此之外，我认为这是一个骗局 Is there such a thing as excessive unit testing?

Answer 7

我会说当你获得了可接受的信心水平。此外，就像我的工作项目一样，我们在如此紧迫的时间要求下，我真的只需要测试代码的某些部分（不是全部）只是为了给我一个很好的置信度。

Answer 8

就数据访问测试而言，您尝试过模拟测试来模拟响应。

Answer 9

我要遵循的基本经验法则是，构建单元测试的努力不仅仅是通过人工重复手动测试该功能的努力。

如果你看一下Visual Studio团队版测试中的测试项目，就会有一个名为“手动测试”的项目，它本质上是一个指令文件，告诉人类如何进行测试并手动传递它。某些事情，比如你提到的UI测试，或代码来解决基础框架或操作系统或驱动程序中的模糊或错误的硬件行为，都会被人眼更好地验证。

Answer 10

如果您使用的是TDD，那么当测试列表中的所有测试都成功时，您就会停止单元测试。

否则，当通过单元测试发现更多错误的成本超过通过QA过程找到错误的成本时，您将停止单元测试。当你通过所有测试的组合达到可接受的代码覆盖水平时。

Answer 11

当项目计划中没有时间时，花时间寻找测试方法而不是努力实现项目目标。