我一直在为花费太多时间处理单元测试回归问题的软件开发团队寻找某种解决方案（在我的案例中大约有 30% 的时间！！！），即处理一天失败的单元测试以天为单位。
以下是我熟悉的一个解决方案，它分析了哪些最新的代码更改导致某个单元测试失败：
我想知道是否有人知道类似的工具，以便我可以对它们进行基准测试。同样，如果有人可以推荐另一种方法来处理这个烦人的问题。
感谢高级
问问题
191 次
3 回答
3
你有我们的同情。听起来你有脆性试验综合症。理想情况下，对单元测试的一次更改应该只会破坏一个测试——这应该是一个真正的问题。就像我说的，“理想”。但这类行为常见且可治疗。
我建议花一些时间与团队一起做一些根本原因分析，以分析为什么所有这些测试都失败了。是的，有一些花哨的工具可以跟踪哪些测试最常失败，哪些测试一起失败。一些持续集成服务器已内置此功能。这很棒。但我怀疑如果你只是问对方，你会知道的。我一直在这样做，团队总是从他们的经验中知道。
任何人，我见过的其他一些导致这种情况的事情：
- 单元测试通常不应该依赖于他们正在测试的类和方法。寻找已经潜入的依赖项。确保您使用依赖项注入来简化测试。
- 这些真的是独一无二的测试吗？还是他们一遍又一遍地测试相同的东西？如果他们总是一起失败，为什么不只删除一个呢？
- 许多人更喜欢集成而不是单元测试，因为他们可以获得更多的覆盖率。但是有了这些，一个单一的改变就可以打破很多测试。也许您正在编写集成测试？
- 也许他们都在通过一些通用的设置代码来运行大量测试，导致它们不一致。也许这可以模拟出来以隔离行为。
于 2010-09-22T07:41:41.173 回答
2
- 关于运行最可能失败的测试的子集 - 因为它通常由于其他团队成员（至少在我的情况下）而失败，我需要让其他人运行我的测试 - 这在某些开发中可能是“政治问题”环境;)。任何其他建议都会被采纳。非常感谢 – SpeeDev 2010 年 9 月 30 日 23:18
如果您必须“请其他人”运行您的测试，那么这表明您的测试基础架构存在严重问题。所有测试（无论是谁编写的）都应该自动运行。修复失败测试的责任应该在于提交更改的人而不是测试作者。
于 2011-01-18T12:04:22.093 回答
2
经常测试，经常提交。
如果您还没有这样做，我建议使用持续集成工具，并要求/要求开发人员在提交之前运行自动化测试。至少是测试的一个子集。如果运行所有测试花费的时间太长，那么使用 CI 工具为每个提交生成一个构建（包括运行所有自动化测试），这样您就可以轻松查看哪个提交破坏了构建。
如果自动化测试太脆弱，也许他们不测试功能，但实现细节？有时测试实现细节是个好主意，但它可能会出现问题。
于 2010-09-22T07:20:13.143 回答