5

我有一个 TeamCity 构建，可以捕获单元测试的代码覆盖率。我还为构建成功的最小代码覆盖率定义了一个环境变量，它工作正常，但我不喜欢手动维护这个阈值。我的问题是是否有一种方法（除了在 TeamCity 之外的某个地方发布代码覆盖率统计数据，然后读取上次成功构建的结果）随着代码覆盖率的提高而自动调整阈值，以确保它是一个稳定的改进而不允许倒退:)？

例如，假设当前代码覆盖率为 20%（遗留应用程序），并且随着新单元测试的编写，代码覆盖率提高到 25%。然后，有人在没有单元测试的情况下签入新代码，代码覆盖率下降到 24%。我希望 TeamCity 构建失败，因为代码覆盖率从 25% 下降到 24%。

4

3 回答 3

9

我有一些关于代码覆盖率的宠物理论，在我开始回答这个问题之前，我想先解释一下。

首先是一些背景：

  • 代码覆盖率有很多种，但我只讨论行覆盖率，但你应该可以替换为不同的类型。
  • 从问题：“......有人在没有单元测试的情况下检查新代码并且代码覆盖率下降......”这与类似的问题有关：“有人（重构/消除重复/替换算法并）删除测试代码和覆盖率滴。”
  • 应根据运行一套测试的结果来衡量覆盖率。也就是说，不是通过运行应用程序并从外部刺激它。
  • 覆盖率是非常具有误导性的。
    我对此进行了思考，实际上您只想知道未涵盖多少行代码。
    请参阅我对此答案的评论：确保对新的 Subversion 提交的覆盖最小
  • 覆盖率应尽可能高。这个问题谈到“......在不允许倒退的情况下进行改进......”
  • 100% 覆盖是可能的。
    我已经做到了，尽管有一个图书馆。

我有一个理论，就代码覆盖率而言，您应该将代码分为两个部分：

  1. 100% 覆盖所有代码的部门。
  2. 没有代码被覆盖的部门。

任何一个部门都可以由多个项目组成，但部门的成员应该是文件（假设 Java 和 C# 都有源文件），最好是整个文件夹的文件。您可以在第一部门拥有一组项目，在第二部门拥有另一组项目。

现在缺乏覆盖的报告只是第二部分的行数。

操作模式应该是您正在测试您的代码，并且代码只是属于 100% 覆盖范围。但是，如果您发现了一段您的大脑无法测试的棘手代码，您应该进行重构，以便将未测试的位移动到第二分区。或者，您可能会得到一个脑电波，并且能够找到一个将第二部分提高到 0% 以上的测试，此时您将代码重构到第一部分。这意味着每次签到都保持我的理论不变性。

现在，回到问题：
不，除了简要查看JetBrains网站外，我根本不了解 TeamCity，所以我不知道如何更新覆盖范围，但根据我的理论，它应该是 100% 或什么都没有，所以你可以为每个项目设置限制吗？如果可以，那么 100% 的固定限制适用于第一师。
如果您可以获得两个部门，您可能希望使用第二部门的代码行数来进行自动更新，逐渐降低更好。

于 2011-04-30T22:20:18.367 回答
2

这是一个老问题，但我想提一下，现在可以通过“故障条件”功能在较新版本的 TeamCity 中实现这一点。故障条件可以使用常量，也可以与之前生成的指标进行比较。在这种情况下，故障情况如下所示：

在此处输入图像描述

于 2015-04-21T14:51:26.750 回答
0

运行测试后，查看覆盖率并将环境变量更新为最接近的五个不大于，也许？

如果您的阈值最初是 25 并且覆盖率跳到 31，请将其更新为 30，如果阈值低于 30，它将中断。当然，您可以在发生跳跃时将其设为 31。

那么在每次测试运行后，你看看当前覆盖率是否大于当前阈值并将阈值设置为新值？

于 2011-05-02T00:21:34.153 回答