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

Question

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

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

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

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

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

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

Answer 1

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

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