logo标签列表

何时应该停止单元测试？

unit-testing
8
我经常会发现许多代码区域非常完美地封装并且易于进行单元测试，但我也发现很多代码单元测试效果不佳，主要是数据访问和用户界面。无论我尝试哪种单元测试“技巧”，我都发现在这些地方创建功能性单元测试不仅需要大量的精力，而且这些测试往往非常脆弱且不能真正测试到很多内容。
在什么时候您会停止并决定放弃单元测试所带来的好处呢？
11个回答
8

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

3

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

2
通常我只测试模型和控制器。对于UI，单元测试很难应用，通常我更喜欢手动测试应用程序。
如果创建这些测试比每次手动测试花费更多的时间，那么测试就是无用的（很容易说，但很难评估...）。
1

如果你需要削减测试，可以削减集成或端到端测试。Google的Misko Hevery在这里非常好地解释了这一点。

“单元测试为你带来更多回报”

是他文章中最好的引用。

除此之外，当你有足够的代码覆盖率并处理了一些代码的边缘情况时，就可以停止单元测试了。

0

如果您可以访问一些实时数据，您可以使用它进行单元测试。此外，您还可以使用数据生成器和随机数据。单元测试只能为您提供一定程度的信心，即它不会在未来出现问题。如果您对自己的测试有信心，您可以停止进行单元测试。

0
0

我认为当你获得了足够的信心水平时就可以开始测试。此外，对于我在工作中的项目，由于时间要求非常紧迫，我只能测试代码的某些部分（而不是全部），以便让我获得足够的信心水平。

0

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

0

我遵循的基本原则是，如果编写单元测试的工作量大于人工反复测试功能的工作量，那么就不必编写单元测试。

如果您查看 Visual Studio Team 版本中的测试项目，会发现有一个名为“手动测试”的项目，它实际上是一份指导文件，告诉人类如何进行测试并手动通过。某些事情，比如您提到的 UI 测试，或者代码需要解决底层框架、操作系统或驱动程序中奇怪或错误行为的问题，最好由人眼来验证。

0

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

否则，当通过单元测试找到更多错误的成本超过通过QA流程找到它们的成本，并且通过所有测试的组合已达到可接受的代码覆盖水平时，您就停止单元测试。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接