unit-testing - "Normal"测试失败时代码库与测试断言问题的比率？

Question

我目前正在处理一个具有一些相当重要的业务规则的项目，其中在我们编写解决方案时“发现”了问题空间(非常典型的困惑项目管理之类的事情)。我们有不错的测试覆盖率并且相当依赖它们以确保我们的重大更改不会破坏任何东西。这种情况是单元测试狂热者强调的一种主要示例，它可以帮助软件立即轻松修改，缺陷更少，完成速度更快，如果您不使用单元测试。想到没有测试套件我将如何应对，我不寒而栗。

我的问题是，虽然我当然相信单元测试的值(value)(这个项目实际上是 TDD，但它与问题并没有真正的密切关系)，但我和其他人一样想知道经典的单元测试问题有这么多要理解和维护的代码(即测试本身)。再次。 毫无疑问，在我看来，这个特定的项目有单元测试比没有它要好得多 ，我还担心测试的长期可维护性。

我根据其他人的建议使用了一些技术来帮助解决这个问题。一般来说，

我们创建了位于“依赖”和“独立”存储桶中的测试列表。独立测试不需要任何不在源代码控制中的东西。因此，对我们的数据访问层的任何调用要么是模拟的，要么是从 xml 文件而不是真实的 db 获取数据。顾名思义，依赖测试依赖于诸如配置文件或数据库或网络事物之类的东西，这些东西在运行测试时可能未正确配置/可用。将测试分成这样的组对于允许我们为早期开发和独立的关键任务测试编写相关的“丢弃”测试非常有值(value)，这些测试可以依赖并抵抗测试腐烂。它还使 CI 服务器易于管理，因为它不必通过 db 连接等进行设置和维护。

我们针对不同级别的代码。例如，我们有针对“main”的测试和针对“main”将调用的所有方法的测试。这使我们能够瞄准系统的细节和总体目标。如果“主要”测试中断，则很难调试，但它们通常不是唯一中断的内容(详细测试也会中断)。遵循详细的测试并在它们中断时调试它们会更容易，但它们不足以知道重构是否会杀死系统(这就是“主要”测试的目的)。

“主要”测试对于让重构没有处理代码库感到舒适至关重要。因此，“主要”测试就像对单个方法的许多测试一样，该方法使用映射到用例的不同 args 调用。它基本上是我们代码的最高级别的入口点，因此可以说不是真正的“单元”测试。然而，我发现我真的需要更高级别的测试，以便让重构不会破坏代码库。较低级别的测试(真正“工作单元”的测试)是不够的。

所有这些都是为了回答问题。随着项目的推进，我发现我需要对代码库实现更改(有时非常重要，有时微不足道)，我发现当更改导致测试失败时， 测试失败与实际回归业务逻辑失败与单元测试无效的比率 .换句话说，有时测试失败是因为实际代码库中的回归错误，有时是因为单元测试断言不再有效而需要更改断言。粗略地说，当测试失败时，对于这个特定项目来说，它大约是(50%)。

有没有人在他们的项目中跟踪过这个比率，如果有，关于这个比率，你学到了什么(如果有的话)？我不确定它是否表明了什么，但我注意到大约一半的测试失败导致我调整测试断言而不是实际修复真实代码库中的回归错误。每当发生这种情况时，我都会觉得我只是浪费了一天中的 x 小时，我想知道我的测试方法是否可以提高效率。解决测试断言失败通常需要比实际回归错误更长的时间，这既违反直觉又令人沮丧。

编辑

请注意，这个问题是关于探索这个比率的含义以及你对这个比率的体验。什么时候“臭”？？

Answer 1

I have noticed that about half the time that test failures lead me to adjusting test asserts rather than actually fixing regression bugs in the real codebase.

当测试失败时，有三个选项:

执行已损坏，应修复，

测试坏了，应该修复，或者

不再需要该测试(因为需求发生变化)，应该删除。

正确识别这三个选项中的哪一个很重要。在我编写测试的方式中，我以测试的名称记录了测试指定/测试的行为，这样当测试失败时，我会很容易找出最初编写测试的原因。我在这里写了更多关于它的内容: http://blog.orfjackal.net/2010/02/three-styles-of-naming-tests.html

在你的情况下，

如果因为需求变化而需要更改测试，并且一次只需要更改几个测试，那么一切正常(测试很好 isolated ，因此每个行为只由一个测试指定)。

如果你因为需求改变而需要改变测试并且一次需要改变很多测试，那么它是 test smell你有很多测试测试相同的东西(测试没有很好地隔离)。测试可能正在测试 more than one interesting behaviour .解决方案是编写更集中的测试和更好的解耦代码。

如果在重构时需要更改测试，那么测试与实现细节耦合得太紧是一种测试味道。尝试编写以系统行为而不是其实现为中心的测试。 The article我之前链接的应该给你一些想法。

(有趣的一点是，如果您发现自己主要是重写类，而不是更改它们，当需求发生变化时，这可能表明代码很好地遵循了 SRP, OCP 和其他设计原则。)