unit-testing - 如何克服单元测试回归问题......？

Question

我一直在为花费太多时间处理单元测试回归问题的软件开发团队寻找某种解决方案(在我的案例中大约有 30% 的时间!!!)，即处理一天失败的单元测试以天为单位。

以下是我熟悉的一个解决方案，它分析了哪些最新的代码更改导致某个单元测试失败:

Unit Test Regression Analysis Tool

我想知道是否有人知道类似的工具，以便我可以对它们进行基准测试。
同样，如果有人可以推荐另一种方法来处理这个烦人的问题。

感谢高级

Answer 1

你有我们的同情。听起来你有脆性试验综合症。理想情况下，对单元测试的一次更改应该只会破坏一个测试——这应该是一个真正的问题。就像我说的，“理想”。但这类行为常见且可治疗。

我建议花一些时间与团队一起做一些根本原因分析，以分析为什么所有这些测试都失败了。是的，有一些花哨的工具可以跟踪哪些测试最常失败，哪些测试一起失败。一些持续集成服务器已内置此功能。这很棒。但我怀疑如果你只是问对方，你会知道的。我一直在这样做，团队总是从他们的经验中知道。

任何人，我见过的其他一些导致这种情况的事情:

单元测试通常不应该依赖于他们正在测试的类和方法。寻找已经潜入的依赖项。确保您使用依赖项注入(inject)来简化测试。

这些真的是独一无二的测试吗？还是他们一遍又一遍地测试相同的东西？如果他们总是一起失败，为什么不只删除一个呢？

许多人更喜欢集成而不是单元测试，因为他们可以获得更多的覆盖率。但是有了这些，一个单一的改变就可以打破很多测试。也许您正在编写集成测试？

也许他们都在通过一些通用的设置代码来运行大量测试，导致它们不一致。也许这可以模拟出来以隔离行为。