我最近开始使用 TDD,或者你可以说为我的项目进行测试,在那里我发现了一些新事物(对我来说是新事物),称为“代码覆盖率”,它显示了在测试过程中你的代码被覆盖了多少。据我所知,大多数老年人常说不可能有 100% 的代码覆盖率,或者获得 100% 的代码覆盖率并不是一个好的做法。这件事让我想知道这个代码覆盖率是如何工作的,我的意思是它们覆盖了哪些基础的代码?请说说Testing的主要用途。
我用这个问题附上了代码覆盖率的图像。
我最近开始使用 TDD,或者你可以说为我的项目进行测试,在那里我发现了一些新事物(对我来说是新事物),称为“代码覆盖率”,它显示了在测试过程中你的代码被覆盖了多少。据我所知,大多数老年人常说不可能有 100% 的代码覆盖率,或者获得 100% 的代码覆盖率并不是一个好的做法。这件事让我想知道这个代码覆盖率是如何工作的,我的意思是它们覆盖了哪些基础的代码?请说说Testing的主要用途。
我用这个问题附上了代码覆盖率的图像。
实际上,100% 的代码覆盖率是可能的,但取决于语言:
关于 100% 代码覆盖率的有用性:
即使 100% 的代码覆盖率也不意味着代码是完美的:
添加:
如果不需要 100% 的代码覆盖率(因为一切都需要时间,因此需要金钱),首先关注代码中的高风险区域。首先跳过琐碎的方法,从复杂/高风险的功能开始。
使用设计模式或代码结构来“帮助”单元测试也很重要:
首先,为了理解代码覆盖率的价值,你必须了解你想用它实现什么。代码覆盖率可帮助您确定程序代码的质量,例如它是否健壮或容易出错、是否具有凝聚力或是否具有隐藏的依赖关系、是否易于更改等。
代码覆盖率高的代码往往是更好的代码,但并不能保证它就是好代码。这是因为代码质量很大程度上取决于您的测试用例的构建程度,例如,如果您正在测试您的预期行为,或者错误或破坏性输入,极端情况或其他特殊情况等。如果您的测试套件很糟糕编写后,您仍然可以实现高(或 100%)的代码覆盖率,但您的代码质量会很低。
其次,大多数有经验的开发人员会告诉你 100% 的测试覆盖率不是必需的,甚至是不好的做法的原因是,你需要投入的时间来使代码覆盖率 100% 更好地投入到更完整的测试套件上。通常,使用编写不佳的测试套件比使用设计良好的测试套件更容易实现 100% 的代码覆盖率。
第三,因为你将(几乎)永远不会有一个完整的测试套件,只是因为我不知道有很多人可以考虑代码可能出错的所有可能情况,所以你应该紧迫地不断修改你的测试套件(不是无限)而不是满足于完全代码覆盖的错误感觉。
我希望这个关于代码覆盖率的观点可以帮助你使它对你更有用。
代码覆盖率很重要,越高越好,因为它表明您的单元测试是彻底的并且已经覆盖了该代码区域,从而减少了错误。
您的应用程序可能不会达到 100% 的代码覆盖率,因为 MSTest 不提供分支、状态覆盖率和测试 void 方法可能很困难。您看到的统计信息基于语句/函数覆盖率。
好吧,我发现代码覆盖率很重要,但不一定要 100% 运行。如果你得到了大约 70% 的代码覆盖率,那么它也很好,如果你得到 100% 的代码覆盖率,那么你的代码也没有必要 100% 正确