代码覆盖率是否应该用作一个“里程碑”,可以阻止项目的进展?

代码覆盖率是一个非常相关的东西。首先,因为代码覆盖率本身并不能告诉您代码或单元测试的质量。其次,有时只需几次测试就可以轻松获得90%的覆盖率,但有时甚至很难达到50%。这对于传统项目尤其如此,这些项目通常不是为了帮助单元测试而设计的(例如为了避免外部依赖)。

如果你真的想把它作为一个里程碑,我的建议是把你的代码分成一些重要的类,比如那些拥有大量业务逻辑的类,然后看看在它上面实现高代码覆盖率是否容易。如果是这样的话,请确保此类类的代码覆盖率始终保持在标准值上。

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

我希望这有帮助!

我认为使用代码覆盖率作为拦截器并不是一条路要走。原因是,有一个良好的覆盖面不是主要目标,它可以变成一个目标本身。只需“运行一些东西”就可以提高度量值,而不是实际测试它。

根据我的经验,最重要的是你 做 运行代码的时候。换句话说,重要的是你的测试不仅仅是运行代码。

但无论如何,使用代码覆盖率作为度量标准,并在代码覆盖率增加时适当庆祝:-)

对于遗留系统,设置这样的屏障对于 整个代码库 ,尤其是当代码基非常大时。你可能弊大于利,特别是因为偿还这些技术债务可能会在不可避免的重构过程中带来额外的不稳定期,而这些重构将涉及到旧代码的更新,而旧代码可能不太适合测试。

我建议只为新代码设置覆盖阈值的有针对性的重构。如果代码库的某个区域很痛苦,并且显示出添加新代码的风险太大,那么就为重新设计和重构留出一些高峰时间。所有修复的错误都应该有失败的测试 先写 ,新特性的目标应该是高覆盖率,大约90%或更高。(传说中的“100%”覆盖率的最后10%通常非常昂贵,因为它可能涉及到gui层和集成材料。这是一个有争议的观点,但我发现这在很大程度上是正确的。对新代码的90%或更高版本感到满意。)

如果覆盖率低于阈值,我当前所在项目的ci服务器将无法生成,但这是在一个以良好tdd实践开始的项目上。拥有大量技术债务的大型遗留应用程序往往会被困在不稳定的领域和政治后果之中,而这些领域和后果不需要比它们已有的更多的创伤。设定一个逐步改进的目标,而不是一次性的追赶。

我认为 代码覆盖度量 有点粗粒度。如果将它限制在代码库的特定区域,则可能会更好一些。但是,你是通过测试属性获得80%的收益,还是通过一个导致你最大问题的怪物方法?

我不会把它当作拐杖。

一般来说:如果你练习scrum(或任何其他敏捷方法),你应该遵循时间拳击原则,避免扩展/延迟你的sprint。

特别是:单独的代码覆盖率度量不足以估计应用程序的测试/准备状态。应该使用更复杂的度量组合(请参阅有关软件测试的书籍)。

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

什么是100%保险?

正确。同时拥有100% 报道是关于 测试的级别 一段代码,就其本身而言,它不能 保证正在测试的代码 完全没有错误。

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

尝试在现有代码上添加测试post hoc可能会导致需要设置数十个依赖项的大型测试设备-代码最初是作为应用程序的一部分而不是在单元测试中编写的。

对我来说,重新审视应用程序的设计并重构可测试的代码是一个值得追求的目标。这可以显著减少技术债务,同时提高代码库的测试能力和维护能力。从商业角度来看,这也可能非常耗时,不值得。

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