应该在每次构建时执行代码覆盖吗？

Question

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

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

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

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

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

这与我目前的商店的做法相反，我们是按照构建执行NCover。我想转到我的领导并要求我们不这样做，但我能做的最好的就是告诉他“这就是布朗菲尔德的书所说的”。我认为这不够好。所以我依靠你们来填补你们关于这个主题的个人经验和建议。感谢。

Answer 1

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

1. 您希望构建尽快运行
2. 您希望构建以尽可能多的反馈运行（例如，运行的测试数量最多，有关构建的稳定性和覆盖范围的最多可用信息等）

您将始终需要权衡并在这些竞争利益之间找到平衡点。我通常会尝试将构建时间保持在10分钟以下，如果需要超过20分钟的时间来提供有关构建稳定性的任何有意义的反馈，我们会考虑构建系统。但这不需要是一个完整的构建来测试每个案例;可能会有其他测试在其他机器上运行以后或并行运行，以进一步测试系统。

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

• 将构建/测试分发到多台计算机上，以便可以并行运行测试，从而获得更快的反馈
• 查找在您的构建中花费大量时间但却没有带来大量好处的事情，并且只将这些任务作为每晚构建的一部分进行。

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

代码覆盖率是一个相对稳定的指标，因为您的代码覆盖率数字在一天内变得非常糟糕的情况相对较少。因此，如果代码覆盖需要很长时间才能执行，那么它在每次构建时都不是很重要。但是你仍然应该尝试每晚至少获取一次代码覆盖率。每晚构建可以允许花费更长的时间，因为（可能）不会有任何人等待它们，但它们仍然定期提供有关项目状态的反馈，并确保没有引入许多不可预见的问题。

也就是说，如果你能够让硬件进行更多的分布式或并行构建/测试，你肯定应该走这条路 - 它会确保你的开发人员尽快知道他们是否破坏了某些东西或引入了问题在系统中。硬件成本很快就会从构建系统的快速反馈中提高生产力中恢复过来。

另外，如果您的构建计算机不能正常工作（即它有很多空闲时间），那么我建议您将其设置为执行以下操作：

• 当代码更改时，请进行构建和测试。省略一些较长时间运行的任务，包括可能的代码覆盖。
• 一旦这个构建/测试周期完成（或并行），就可以开始更长时间的构建，更彻底地测试事情，代码覆盖等等。
• 这两个版本都应提供有关系统健康状况的反馈

这样，只要构建计算机具有容量，就可以获得快速反馈，但也可以为每个构建获得更多的扩展测试。

Answer 2

我不会对如何解决这个问题做出任何假设 - 你把马放在马前面。你有一个抱怨，认为构建需要太长时间，所以这是我要求解决的问题，没有关于如何做到这一点的先入为主的观念。这个问题有许多其他潜在的解决方案（更快的机器，不同的流程等），你最好不要排除它们中的任何一个。

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

Answer 3

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

Answer 4

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

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

如果构建机器没有其他任何操作，那么它是否也这样做并不重要。 如果您的构建计算机太忙于构建，可能是因为要求它为太多主服务器服务而超负荷，或者您正在做太多构建（为什么这么多更改？嗯，也许测试不是很好！）

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

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

[如果你是偏执狂并且不相信增量测试过程，你可以运行它们以获得早期反馈，然后继续再次运行所有测试，给你全部结果。]