计数断言答案

【问题标题】：Counting assertions计数断言
【发布时间】：2014-02-13 19:13:28
【问题描述】：

我最近收到了来自管理层的请求，要求我为我们的软件测试运行的断言数量创建报告。他们想要这个，以便他们可以判断人们是否正在编写测试。我倾向于只是告诉他们“不，你不能拥有它，因为你不需要它”，但这似乎并不能满足他们。

部分问题在于我们的团队正在编写包含大量断言的长测试用例，并且他们想说他们已经测试了一些新功能，因为他们在现有测试用例中添加了更多断言。

所以我的问题是：有没有人有一些好的、权威的（尽可能多的）资源或文章或书籍，甚至描述了如何将测试分成测试用例或为什么计数断言不好？

我的意思是计算每个测试的断言或断言来衡量人们是否正确测试与计算每个测试的代码行数一样有用。但他们就是不买。我尝试用 Google 搜索，但问题是 没有人费心计算断言，所以我不能说“这就是为什么这是一个坏主意”。

【问题讨论】：

只是我的看法：您会发现覆盖率是一个更有用的统计数据。我可以写一千个断言，只测试一行代码。
当然，我们目前不测量覆盖率（我们希望，但无需过多讨论，编写代码的语言使这非常困难）。我不是在寻找“覆盖率是一个更好的指标”，而是在寻找“为什么计算断言是一个糟糕的指标”。
一位同事在 junit 文档中指出了我在搜索中不知何故错过的这个页面：junit.sourceforge.net/doc/faq/faq.htm#tests_12 我不确定这是否足以算作这个问题的答案。
为什么不定期演示测试（冲刺结束、发布前、月末......），然后他们知道你是否编写测试。但对我来说，这听起来像是微观管理出了问题。他们应该对质量感兴趣，而不是你用来提高质量的工具（单元测试）。我可以推荐在 (pragprog.com) 上找到的实用单元测试书籍。
对该问题的进一步调查显示，团队编写的内部测试框架不会因断言失败而停止，这很疯狂。这在某种程度上解释了为什么他们试图在一种测试方法中填充如此多的断言，因为他们不介意是否有一些失败并认为他们仍在测试“某些东西”。但是这些测试非常脆弱，一旦失败就很难说出原因。 -_-

标签： unit-testing tdd xunit code-metrics

【解决方案1】：

在软件管理中做出愚蠢决定的想象力真的没有限制，计算断言？？...测试的问题通常是质量问题而不是数量问题。

如果您想要一个受人尊敬的参考资料，Gerard Meszaros xUnits 可能是最受人尊敬的参考之一，其建议之一是“每次测试验证一个条件”(http://books.google.es/books?id=-izOiCEIABQC&lpg=PT111&ots=YIeYejY-mx&dq=meszaros%20one%20assertion%20per%20test&hl=es&pg=PT110#v=onepage&q=condition&f=false)

但是...如果问题在于人们添加“新测试场景”以“更多断言”扩展现有测试而不是编写新测试，那么贵公司可以尽其所能购买大量的 meszaros 书（并以 TDD 为例，并在测试指导下发展面向对象）并聘请一些专家进行培训和指导。

【讨论】：

我现在将其标记为答案，因为我喜欢您引用的那本 google 书中的解释。您还提到了 Kent Beck，这里的人们确实尊重他作为 TDD 的权威。在他的书需要第 125 页的中间谈到测试隔离时，他说：“如果我有一个测试失败，我想要一个问题。”计算断言并不是真正的问题，问题是巨大的测试方法是由于在现有测试中添加更多东西（断言）而不是进行新测试而导致的。

【解决方案2】：

也许敏捷宣言说得最好：

围绕有动力的个人构建项目。给他们环境和他们需要的支持，并相信他们能够完成工作。

如果您尝试按指标运行项目，您最终会得到您所衡量的任何东西，例如，很多断言实际上并没有测试正确的东西。

或者从更一般的管理角度来看：http://hbr.org/2010/06/column-you-are-what-you-measure/ar/1

【讨论】：

【解决方案3】：

Steve McConnel 编写的 Code Complete 一书涵盖了代码和测试质量方面，包括与您的案例相关的指标。

指标应该激发理想的行为。就您而言，理想的行为是编写更好的测试。因此，请尝试向您的经理解释，计数断言与理想行为无关。它实际上会导致不良行为，在此处的其他答案中提到。

我同意敏捷宣言中的观点。但是，它可以在健康的环境中成功应用。我观察到一些工程师拒绝编写单元测试的案例，因为他们认为没有它们，他们在过去 20 年左右的时间里是“成功的”。在这种情况下，您对他们完成工作的信任程度并不重要。指标改变行为。他们生成无偏见的数据，以便做出更好的决策。它们很有用，但如果它们是正确的指标。

祝你好运！

【讨论】：

【解决方案4】：

也许造成这种情况的根本原因是长时间的测试方法导致缺乏可见性。真的每个测试都应该写一个逻辑断言（这可以是一组断言，但实际上应该尽可能少地测试给定的场景），再多的话，测试的可读性就会降低，而且人们更难理解什么它的实际测试。这些也更容易维护，并且当被测系统发生变化时也更容易改变。冗长的测试方法也往往非常脆弱，因为它们涵盖了太多的系统行为，并且每次发生任何变化时都需要进行更改。

我找不到手头的示例，但 Kent Beck 和 Mark Seemann 提供了一些很好的资源。 This 与这个问题非常相关。

指标本身总是会被欺骗，您可以获得 100% 的代码覆盖率，使用大量断言而不实际测试任何东西，至少在最初清理测试时，您可能会获得更多价值。

【讨论】：

我真的很喜欢你链接到的programmers.stackexchange.com question 中所述的想法：测试应该因一个原因而失败。这才是真正的问题，因为这些测试可能会因......数百个原因而失败。
@ZombieDev 编写具有 100% 代码覆盖率且无断言的测试。这个测试套件将永远变成绿色。如果要求是，那么测试应该由于一个原因而失败，而不是每个测试应该有 100 个测试、100 个断言和 1 个断言。如果你有 100 个测试并且只有 20 个测试有断言，80 个测试没有，那么我建议删除 80 个测试，因为代码质量和运行这个假测试的成本为零。