我是一个项目的开发经理,单元测试代码覆盖率非常低,我们肯定会感受到系统遗留代码中"技术负债"的重要性.
我的问题是,是否有人使用代码覆盖率作为里程碑或开发阈值,阻止项目移动到下一个sprint,直到代码覆盖率达到特定级别？使用代码覆盖率指标的"最佳做法"是什么？
代码覆盖率是一个非常相关的事情.首先,因为代码覆盖率本身并不能告诉您代码质量或单元测试.其次,有时很容易通过少量测试获得90%的覆盖率,但有时甚至很难达到50%.遗留项目尤其如此,这些项目通常不是为了帮助进行单元测试而设计的(例如,为了避免外部依赖).
如果你真的想把它作为一个里程碑,我的建议是采用一些重要的代码类,例如那些拥有大量业务逻辑的代码,并看看它是否很容易实现高代码覆盖率.如果是这种情况,请确保此类的代码覆盖率始终保持不变.
我的经验告诉我,在遗留类上获得高代码覆盖需要花费大量时间,而且这并不值得投资.
我希望这有帮助!
我认为使用代码覆盖作为阻止程序是不可取的.原因是拥有良好的覆盖范围不是主要目标,而且它本身可以变成目标.只需"运行东西"即可获得指标,而不是实际测试它.
所以,在我的经验中,最重要的是,你实际上做的东西,而运行的代码.换句话说,重要的是你的测试测试而不仅仅是运行代码.
但无论如何,使用代码覆盖率作为指标,并在它增加时适当地庆祝:-)
| 归档时间： |
|
| 查看次数： |
273 次 |
| 最近记录： |