continuous-integration - 是否应该在每次构建时执行代码覆盖率？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




10年前关闭。




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

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

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

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

出于这些原因，我们建议将代码覆盖任务与
构建脚本的默认任务。它应该定期运行，也许作为你的构建文件中的一个单独的计划任务，每两周甚至每月执行一次，但我们
不觉得该指标有足够的好处来保证额外的开销
它在每次登记入住时执行。”

这与我当前商店的做法相反，我们在每次构建时执行 NCover。我想去找我的领导并要求我们不要这样做，但我能做的最好的事情就是告诉他“这就是 Brownfield 的书所说的”。我认为这还不够好。因此，我依靠你们来为我提供有关此主题的个人经验和建议。谢谢。

Answer 1

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

您希望构建尽快运行

您希望构建以尽可能多的反馈运行(例如，运行的测试数量最多，有关构建稳定性和覆盖率的可用信息量最大等)

您将始终需要权衡利弊，并在这些相互竞争的利益之间找到平衡。我通常尽量将构建时间保持在 10 分钟以内，如果需要超过 20 分钟才能给出有关构建稳定性的任何有意义的反馈，我会认为构建系统已损坏。但这不需要是测试每个案例的完整构建；可能会有其他测试稍后或在其他机器上并行运行，以进一步测试系统。

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

将构建/测试分发到多台机器上，以便测试可以并行运行，您可以获得更快的反馈

找出在您的构建中花费大量时间但没有带来很多好处的事情，并且仅将这些任务作为每晚构建的一部分来执行

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

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

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

此外，如果您的构建机器不是一直在工作(即有很多时间空闲)，那么我建议将其设置为执行以下操作:

当有代码更改时，进行构建和测试。忽略一些运行时间较长的任务，包括潜在的代码覆盖率。

一旦这个构建/测试周期完成(或并行)，开始一个更长的构建，更彻底地测试事物，代码覆盖等

这两个版本都应该提供有关系统健康状况的反馈

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