5

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

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

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

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

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

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

4

4 回答 4

3

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

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

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

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

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

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

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

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

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

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

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

于 2011-06-29T02:32:47.100 回答
2

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

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

于 2011-06-27T20:09:37.813 回答
1

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

于 2011-06-27T20:10:27.180 回答
0

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

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

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

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

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

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

于 2011-06-27T21:00:51.277 回答