太粗暴了！拿单测覆盖率当质量门禁

文章指出，将单元测试覆盖率作为质量门禁的做法存在问题，并探讨了其中的逻辑链条错误。特别强调了全量和增量单测覆盖率都不应作为无情的质量门禁。

首先，将全量单测覆盖率作为质量门禁可能导致懒惰的程序员通过门禁，即使他们没有编写应有的单元测试。这是因为即使不增加单元测试，全量覆盖率可能依然高于设定的阈值，导致门禁失效。

其次，增量单测覆盖率在某些情况下，如代码变动简单时，强制编写单元测试会显得不必要，甚至可能导致编写的模拟代码比实际代码还多。

作为解决方案，文章建议增量覆盖率仍然是值得关注的指标，但不应该作为严格的门禁。它可以展示在合并请求中，作为代码审查的参考，而不是强制要求。全量覆盖率也很重要，但不应在每个合并请求中检查，因为它与特定特性的相关性较小。如果全量覆盖率较低，应鼓励编写新代码时总是包含适当的单元测试，并可能分配专项任务来补足历史遗留的问题。

文章总结指出，只有通过建立合理的机制和关注适当的指标，单元测试覆盖率才能真正有助于提高软件质量。更详细的信息和解释可以在《高质效交付》这本书中找到。