我们应该排除代码进行代码覆盖率分析吗？

我正在开发几个应用程序，主要是遗留应用程序。当前，它们的代码覆盖率非常低：通常在10％到50％之间。

自几周以来，我们与班加罗尔团队进行了周期性讨论（开发的主要部分在印度境外进行），以排除Cobertura的软件包或类（我们的代码覆盖率工具，即使我们当前正在迁移到JaCoCo）也是如此。

他们的观点如下：由于他们不会在应用程序的某些层上编写任何单元测试（1），因此应将这些层简单地排除在代码覆盖率范围之外。换句话说，他们希望将代码覆盖率度量标准限制为已测试或应该测试的代码。

同样，当他们为复杂的类进行单元测试时，由于在大型应用程序中所带来的好处-仅在代码覆盖率方面-不会被注意到。减少代码覆盖范围的范围将使这种工作更加明显。

这种方法的好处是我们将有一个代码覆盖率度量，它指示我们认为可测试的应用程序部分的当前状态。

但是，我的观点是我们在某种程度上伪造了数字。该解决方案是轻松实现更高级别代码覆盖率的简便方法。令我困扰的另一点是：如果我们显示从一个星期到另一个星期的覆盖率增加，我们如何分辨这个好消息是由于开发人员的良好工作还是仅仅是由于新的排除因素？

此外，我们将无法确切知道代码覆盖率度量中考虑的内容。例如，如果我有10,000行代码应用程序，且代码覆盖率达到40％，则可以推断出40％的代码库已经过测试（2）。但是，如果我们设置排除条件会怎样？如果现在代码覆盖率达到60％，我该如何准确扣除？我的“重要”代码库中有60％经过测试了吗？我怎么能够

就我而言，即使我们对此不太满意，我还是希望保留“真实的”代码覆盖率值。此外，借助Sonar，我们可以轻松地在代码库中导航，并知道任何模块/包/类的代码覆盖范围。但是，当然，全球代码覆盖率仍然很低。

您对该主题有何看法？您如何处理项目？

谢谢。

（1）这些层通常与UI / Java bean等有关。

（2）我知道那不是事实。实际上，这仅意味着我的代码库的40％

我通常排除自动生成的代码，例如Visual Studio生成的WCF客户端。通常那里有很多代码行，我们永远不会去测试它们。这使得在其他地方增加对大量代码的测试变得非常令人沮丧，并且仅将代码覆盖率提高了0.1％。

我还将排除数据层交互，只要团队可以确定地说该层尽可能薄即可。尽管您可以辩称，如果该层很薄，则不会产生很大的影响，但确实会在覆盖率报告中留下很多组件，而对它们的影响为0％，因此我们不一定会注意到我们需要的组件真正担心。根据所使用的框架，可以类似的方式争论UI层。

但是，作为对策，我也将排除单元测试本身。它们应始终具有约100％的覆盖率，并且它们占代码库的很大一部分，从而使数字危险地向上倾斜。

好问题。通常，出于某些原因，我倾向于将代码从代码覆盖率中排除，例如：

• 产生的
• 旧版（不再更新）
• 它来了：某些层，我不打算测试

为什么最后一点？我认为，专注于我关心的事情，同时抑制分心是一种好习惯。如果您不想测试UI层，为什么要考虑它-它只会将注意力从软件的重要部分-业务逻辑上转移开。

但：

1. 您应该有一个很好的理由，为什么不将某个层完全排除在单元测试之外（可能会有问题-来自您的老板，您的队友，新闻界;-)
2. 如果您希望他们测试这些层，则应将它们包括在统计数据中，以向整个团队展示每天重要的事情和需要完成的事情。

最后：不要太看重数字。如果30％的覆盖率是软件不可或缺的部分，则可以证明它是坚如磐石的。

我倾向于同意您的看法，并将所有相关代码包括在代码覆盖率指标（以及Sonar中）。即使您不打算测试代码的某些部分（在可预见的将来），指标也应反映实际状态。这迫使您有充分的理由不对代码库的大部分内容编写测试。最终（一旦代码中其他更重要的部分都被覆盖了），您可以重新考虑，或选择其他方法消除这种不协调感-例如，通过重构相关代码以使其可测试，或将所有逻辑从其中迁移到代码库中不同的，可测试的部分，或者甚至完全消除了整个层（如果一个层不值得测试，是否有足够的理由存在？）

在我当前的项目中，我们还将所有代码都包含在指标中，但有一个例外：生成的代码，产生大量的静态分析警告。由于此代码通常由庞大的POD类组成，没有任何逻辑，因此无论如何都无需进行测试。

现在，我对您所使用的代码覆盖工具并不太熟悉，也不熟悉Java Bean，但是从您所说的来看，它们与UI相关。

据我所知，我只能说：

1. 不要让任何测试工具的数字妨碍您的测试。
2. 如果这些类很复杂并且不能进行单元测试，则最好将它们重构为更紧凑和可测试的类。这将需要大量的努力和奉献精神，但从长远来看将是有回报的。
3. 测试UI组件可能很困难，但是您仍然可以测试这些组件正在执行的功能。
4. 如果您正在执行基于Web的项目，则可以使用QUnit对所有客户端代码进行单元测试。

总而言之，您应该记住，代码覆盖率只是一个数字，而较高的代码覆盖率并不表示良好的测试。专注于使核心库更健壮和可测试，而不是追求更高的百分比。

某些排除是有意义的（对您的项目正常运行没有实际影响或潜在影响的样板代码）。即使仍然收集代码覆盖率作为指标也是没有意义的，因为它仍然无法告诉您任何有用的信息。100％的代码覆盖率不是一个真正的目标，根据项目的不同，覆盖率低也可能并不坏，有可能20-30％的代码覆盖率涵盖了所有值得测试的内容。代码覆盖率仅告诉您X％的代码实际上可能值得通过某种未知质量的测试覆盖。

我建议为您的代码的每一层报告一组指标。这些度量应该包括大小信息（例如，LoC，库数，类或方法的数目等），测试信息（例如，覆盖率）和错误信息（例如，查找和修复率）。

您排除的图层将具有0％的覆盖率，而您的测试区域将具有您提到的60％的覆盖率。尺寸信息将使人们了解未经测试或测试的数量。错误信息将通知您是否应该为排除的层创建测试，以及现有的测试是否有效。

软件组织很容易过于关注指标的纯度。我们不制定指标，而是打造优秀的软件。可以帮助您及时交付高质量软件的衡量标准是最诚实，最纯粹的衡量标准。