代码覆盖是否应该用作阻碍项目进展的“里程碑”？

Question

我是一个项目的开发经理，单元测试代码覆盖率很低，我们肯定会感受到系统遗留代码中“技术负债”的重要性。

我的问题是，是否有人使用代码覆盖率作为里程碑或开发阈值，阻止项目移动到下一个sprint，直到代码覆盖率达到特定级别？使用代码覆盖率指标的“最佳做法”是什么？

Answer 1

代码覆盖率是一个非常相关的事情。首先，因为代码覆盖率本身并不能告诉您代码质量或单元测试。其次，有时很容易通过少量测试获得90％的覆盖率，但有时甚至很难达到50％。遗留项目尤其如此，这些项目往往不是为了帮助进行单元测试（例如，为了避免外部依赖）。

如果您真的想将它用作里程碑，我的建议是采用一些重要的代码类，例如那些拥有大量业务逻辑的代码，并查看是否很容易实现高代码覆盖率％ 。如果是这种情况，请确保此类的代码覆盖率始终保持不变。

我的经验告诉我，在遗留类上获得高代码覆盖需要花费大量时间，而且这并不值得投资。

我希望这有帮助！

Answer 2

我认为使用代码覆盖作为阻止程序是不可取的。原因是拥有良好的覆盖范围不是主要目标，而且它本身可以变成目标。只需“运行内容”即可获得指标，而不是实际测试它。

因此，根据我的经验，最重要的是您在运行代码时实际上做某事。换句话说，重要的是你的测试测试而不仅仅是运行代码。

但无论如何，请使用代码覆盖率作为指标，并在增加时适当地庆祝： - ）

Answer 3

对于遗留系统来说，设置这样的障碍对于整个代码库来说可能太痛苦了，特别是如果代码库非常大。你可以弊大于利，特别是因为偿还这种技术债务可能会在不可避免的重构过程中产生额外的不稳定时期，这些重构可能会涉及到追赶旧代码，这可能不是非常适合测试的。

我建议使用仅针对新代码设置的覆盖率阈值进行有针对性的重构。如果代码库的一个区域很痛苦并且显示添加新代码的风险太大，那么阻止重新设计和重构的一些峰值时间。所有修复的错误都应该进行首先编写的失败测试，​​并且新功能应该针对高覆盖率，大约90％或更高。 （传说中“100％”覆盖率的最后10％通常非常昂贵，因为它可能涉及GUI层和集成材料。这是一个有争议的观点，但我发现它在大多数情况下都适用。新代码的90％或更高。）

如果覆盖率低于阈值，我目前正在进行的项目的CI服务器将失败，但这是在一个以良好的TDD实践开始的项目上。拥有大量技术债务的大型遗留应用程序往往会陷入困境，不稳定的地区和政治后果不再需要任何创伤。设定一个逐步改善的目标，而不是一次性追赶。

Answer 4

一般情况下：如果你练习Scrum（或任何其他敏捷方法），你应该遵循时间限制原则，避免延长/延迟你的冲刺。

特别是：仅代码覆盖率指标不足以估计应用程序的测试/准备状态。应该使用更复杂的度量组合（参考有关软件测试的书籍）。

Answer 5

我认为代码覆盖率指标有点粗粒度可以这样使用。如果将它限制在代码库的特定区域，它可能会更好一些。但是，你是通过测试属性获得80％，还是那种导致你遇到最多问题的怪物方法？

我不会用它作为拐杖。

Answer 6

高代码覆盖率指标不保证代码质量。来自“The Meaning of 100% Test Coverage”

  

100％覆盖率意味着什么？

     

正确性。虽然有100％   报道是一个强有力的声明   进入的测试水平   一段代码，它本身就不能   保证正在测试的代码   是完全没有错误的。

作为测试驱动开发的一部分创建单元测试的主要优点之一是将代码引导到更加可测试的状态。

尝试在post-hoc上对现有代码添加测试可能会导致需要设置大量依赖项的巨大测试装置 - 代码最初编写为作为应用程序的一部分进行测试，而不是单元测试。

重新审视应用程序的设计并重构代码以供我测试，这将是一个有价值的目标。这可能会显着降低技术债务，同时提高代码库的测试能力和维护能力。从商业角度来看，它也可能非常耗时并且不值得。

Answer 7

如果你正在处理“遗留代码”，使用覆盖率作为拦截器会让你感到痛苦。要求任何编写/重构的新代码都在覆盖范围内，并且您测试的遗留代码的百分比应该随着时间的推移自然增加，如果您使用覆盖率作为阻止程序，您将不太可能获得人为的安全感。