每次构建都应该执行代码覆盖率吗？ [关闭]答案

【问题标题】：Should code coverage be executed EVERY build? [closed]每次构建都应该执行代码覆盖率吗？ [关闭]
【发布时间】：2011-09-23 19:21:47
【问题描述】：

我是棕地应用程序开发的忠实粉丝。毫无疑问，这是一本很棒的书，我会向所有开发者推荐它。我在这里是因为我在书中谈到了代码覆盖率。在我的新商店，我们使用 Team City 进行自动化构建/持续集成，构建完成大约需要 40 分钟。布朗菲尔德的书谈到了无摩擦开发以及我们如何减轻开发人员必须承受的共同负担。这是我在第 130 页读到的内容..

“代码覆盖率：一个价格的两个过程？从清单 5.2 中的示例目标可以看出，您最终会得到两个输出文件：一份是测试结果，一份是代码覆盖率结果。这是因为你实际上是在这个任务期间执行你的测试。

如果您正在运行，从技术上讲，您不需要在单独的任务中执行测试代码覆盖任务。出于这个原因，许多团队将替代自动化测试任务的代码覆盖任务，本质上是在 CI 过程。 CI 服务器将编译代码、测试它并生成代码覆盖率每次签到的统计信息。

虽然这种方法在概念上没有任何问题，但请注意一些缺点。首先，生成代码覆盖率统计信息会产生开销。什么时候有很多测试，这种开销可能足以引起摩擦运行时间较长的自动构建脚本的形式。请记住，主要构建脚本应尽可能快地运行，以鼓励团队成员经常运行它。如果运行时间太长，您可能会发现开发人员正在寻找解决方法。

出于这些原因，我们建议单独执行代码覆盖任务构建脚本的默认任务。它应该定期运行，可能作为构建文件中的一个单独的计划任务，每两周甚至每月执行一次，但是我们认为该指标没有足够的好处来保证拥有的额外开销它在每次签到时执行。”

这与我当前商店的做法相反，我们每次构建都执行 NCover。我想去找我的领导并要求我们不要这样做，但我能做的最好的就是告诉他“这就是布朗菲尔德书上所说的”。我认为这还不够好。所以我依靠你们来向我介绍你们在这个话题上的个人经历和建议。谢谢。

【问题讨论】：

为什么要在每次构建时停止 NCover？
我为什么要停止它？我并不是在提倡我想阻止它。这就是我问这个问题的原因。老实说，我不确定。我只知道有时会一样。我想知道锻炼是否是一种有效的权衡。
你怎么知道它会节省一些时间？ NCover 应该是您的测试的并发操作，增加很少的开销。
@Nick 在这种情况下我们都是假设的。这里真正需要发生的是让我弄清楚 NCover 需要多长时间。但是你说“应该”就好像你也不确定。仍然需要生成统计信息。发生在什么级别的并行性？我不知道。你？它肯定会与你有多少测试成正比。
我并没有真正假设任何事情——我只是在问问题。我说 NCover “应该”是一个并发操作，因为这是最有效地设置（并且通常）的方式，但我显然对您的设置没有任何特别的见解 - 可能您在运行测试后再次连续运行它，这将是非常低效的。

标签： continuous-integration teamcity code-analysis code-metrics ncover

【解决方案1】：

我不会对如何解决这个问题做出任何假设 - 你在这里有点本末倒置。您抱怨构建时间太长，所以这就是我要解决的问题，没有关于如何做的先入为主的概念。这个问题还有许多其他潜在的解决方案（更快的机器、不同的流程等），明智的做法是不要排除其中任何一个。

归根结底，这是一个问题，即您的管理层是否重视构建系统的输出，足以证明所花费的时间是合理的。（以及您可能采取的任何措施来弥补时间消耗是否具有可接受的输出保真度）。

【讨论】：

这不是投诉。但我确信少一项任务会缩短构建时间。这是一个合乎逻辑的想法。如果我为特定算法执行了 5 个方法，并且我删除了其中一个，我可以保证按时减少。哪怕只有一纳秒。我选择代码覆盖率的原因是因为它是你可以设法在几次构建中不用的东西之一。另一方面，每个构建都应该执行单元测试。
@A-Dubb：为什么你更看重单元测试而不是覆盖率？如果您认为单元测试是绝对必要的，您是否也认为验证您正在运行的单元测试实际上涵盖了您的所有代码是必不可少的？例如，为什么可能运行一组无效的单元测试是可以接受的。如果您已经在运行单元测试，那么 NCover 会大大延长时间，这似乎也很奇怪——这应该是一个单一的操作。
另外，也许你知道它需要多少时间，但你肯定没有在这里建立它。当然，从算法中删除一种方法会节省您的时间，但如果 99% 的时间花在其他 4 种方法上，您的时间可能会更好地用于研究其他解决方案。
是的。确实如此。我不确定 NCover 执行需要多长时间，但我敢打赌，如果执行频率较低，它所花费的时间足以减轻相当多的痛苦。不过，我会调查确切的数字。

【解决方案2】：

这是每个团队和每个环境的决定。您应该首先确定构建持续时间的阈值，然后将运行时间较长的进程分解为发生频率较低的事件（理想情况下，在 CI 中每天不少于 1 或 2 次）。

【讨论】：

所以你的意思是它不应该为每个构建都执行，而是最多合并为一天两次？
嗯...不。至少和仅一次或两次，如果它超过了您预定的构建长度阈值。

【解决方案3】：

反对意见似乎是执行所有测试并收集代码覆盖率很昂贵，而且您不（好吧，有人不想）为每个构建支付这个价格。

我无法想象你（或那个人）到底为什么不想总是知道覆盖状态是什么。

如果构建机器无事可做，那么它是否也这样做也没关系。如果您的构建机器忙于构建，可能是您要求它为太多的主服务器服务而使其超载，或者您正在执行太多构建（为什么要进行如此多的更改？嗯，也许测试不是很好！） .

如果问题在于测试本身确实需要很长时间，您或许可以找到优化测试的方法。特别是，您不需要为未更改的代码部分重新运行测试。弄清楚如何做到这一点（并相信它）可能是一个挑战。

一些测试覆盖率工具（例如ours）使您能够跟踪哪些测试覆盖了代码的哪一部分，并且在代码更改的情况下，哪些测试需要重新运行。通过一些额外的脚本，您可以简单地重新运行首先受到影响的测试；这使您能够在不运行所有测试的情况下及早/快速地获得完整的测试结果。然后，如果构建有问题，您会尽快发现。

[如果您偏执并且不真正信任增量测试过程，您可以运行它们以获得早期反馈，然后再次运行所有测试，为您提供完整的结果。]

【讨论】：

很公平。似乎有一种挥之不去的情绪，即代码覆盖率非常重要，在每个构建的基础上都可以忽略。我对这个问题没有特别的立场。这更像是一个开放式问题，看看你们的想法。我只是想从你们那里得到反馈，以了解最常见的偏好。

【解决方案4】：

在持续集成/自动构建系统中总是存在两个相互竞争的利益：

您希望构建尽快运行
您希望构建在运行时得到尽可能多的反馈（例如，运行的测试数量最多、关于构建稳定性和覆盖范围的可用信息最多等）

您总是需要权衡取舍，并在这些相互竞争的利益之间找到平衡点。我通常会尝试将构建时间控制在 10 分钟以下，如果需要超过 20 分钟的时间才能对构建的稳定性提供任何有意义的反馈，我会认为构建系统已损坏。但这不需要是一个测试每个案例的完整构建；可能会有其他测试稍后运行或在其他机器上并行运行以进一步测试系统。

如果您看到构建时间为 40 分钟，我建议您尽快执行以下操作之一：

将构建/测试分发到多台机器上，以便测试可以并行运行，您可以获得更快的反馈
找出在您的构建中花费大量时间但没有带来很多好处的事情，并且只在夜间构建中执行这些任务

如果可能的话，我会100% 推荐第一个解决方案。但是，有时硬件无法立即使用，我们必须做出牺牲。

代码覆盖率是一个相对稳定的指标，因为您的代码覆盖率数字在一天之内会急剧恶化的情况相对较少。因此，如果代码覆盖需要很长时间才能执行，那么在每个构建中都发生它并不是很重要。但是您仍然应该尝试至少每晚一次获取代码覆盖率。每晚构建可能需要更长的时间，因为（大概）不会有人在等待它们，但它们仍会定期提供有关您项目状态的反馈，并确保不会引入很多不可预见的问题。

也就是说，如果您能够让硬件进行更多分布式或并行构建/测试，那么您绝对应该走这条路 - 这将确保您的开发人员尽快知道他们是否破坏了某些东西或引入了问题在系统中。硬件成本将很快从构建系统的快速反馈所带来的生产力提高中得到回报。

另外，如果您的构建机器不是一直在工作（即有很多时间处于空闲状态），那么我建议您将其设置为执行以下操作：

当有代码更改时，进行构建和测试。省略一些运行时间较长的任务，包括潜在的代码覆盖率。
一旦此构建/测试周期完成（或并行），启动更长的构建，以更彻底地测试事物、进行代码覆盖等
这两个版本都应该提供有关系统运行状况的反馈

这样，您可以获得快速反馈，但也可以为每个构建获得更多扩展测试，只要构建机器有能力。

【讨论】：