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

Question

我正在为软件开发团队寻找某种解决方案，这些解决方案花费了太多时间处理单元测试回归问题（在我的情况下大约30％的时间!!!），即处理单元测试失败的问题日复一日。

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

Unit Test Regression Analysis Tool

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

感谢高级

Answer 1

你有同情心。听起来你有脆弱测试综合症。理想情况下，对单元测试的单个更改应该只能打破一个测试 - 这应该是一个真正的问题。就像我说的那样，“理想”。但这种行为是常见和可治疗的。

我建议花一些时间与团队进行一些根本原因分析，了解所有这些测试的原因。是的，有一些奇特的工具可以跟踪哪些测试最常失败，哪些测试失败。一些持续集成的服务器内置了这个。这很棒。但我怀疑如果你只是问对方，你会知道的。我一直都是这样，团队总是从他们的经历中知道。

Anywho，我见过的其他一些事情导致了这个：

• 单元测试通常不应该依赖于他们测试的类和方法。寻找已经悄悄进入的依赖关系。确保使用依赖注入来简化测试。
• 这些真正独一无二的测试吗？或者他们一遍又一遍地测试同样的事情？如果他们总是会一起失败，为什么不删除除了一个以外的所有人？
• 许多人喜欢整合而不是单元测试，因为他们可以获得更多的报道。但有了这些，一次改变就会破坏大量的测试。也许你正在编写集成测试？
• 也许他们都在运行一些常见的设置代码进行大量测试，导致他们齐声突破。也许这可以被嘲笑以隔离行为。

Answer 2

经常测试，经常提交。

如果您不这样做，我建议使用Continuous Integration工具，并要求/要求开发人员在提交之前运行自动化测试。至少一部分测试。如果运行所有测试花费的时间太长，那么使用CI工具为每个提交生成一个构建（包括运行所有自动化测试），这样您就可以很容易地看到哪个提交破坏了构建。

如果自动化测试太脆弱，可能他们不测试功能，但是实现细节？有时测试实现细节是一个好主意，但它可能会有问题。

Answer 3

  

  
1. 关于运行最可能的测试失败的子集 - 因为它通常由于其他团队成员而失败（至少在我的情况下），我需要让其他人运行我的测试 - 这可能在某些方面存在'政治问题'的开发环境;）。任何其他建议都将得到满足。非常感谢 - SpeeDev 2010年9月30日23:18
  

如果您必须“请求其他人”运行您的测试，那么这表明您的测试基础架构存在严重问题。 所有测试（无论是谁编写）都应该自动运行。修复失败测试的责任应该由提交更改而不是测试作者的人负责。