在单元测试覆盖率中要考虑什么？答案

【问题标题】：What to consider in Unit test coverage?在单元测试覆盖率中要考虑什么？
【发布时间】：2016-05-31 13:52:24
【问题描述】：

我有一个包含数据、数据访问和服务组件的 C# 实体框架项目。 Config 管理员已启用代码覆盖率 (Sonarqube)，目前显示数据和数据访问组件的覆盖率为 0%。

1) 虽然为 Service 组件的 class 方法编写的 MSTest 单元测试代码正在执行类似 --> Student s = new Student() （Student 是 Data 组件中的公共类）我认为它不会被考虑在内作为数据组件的覆盖线？我验证了即使编写了一个虚拟测试来检查是否在新的测试方法中调用构造函数，它仍然会将无逻辑数据类 Student 标记为未覆盖。这是预期的吗？

2) Entity 框架数据组件几乎没有业务逻辑，因为它只有流畅的 api 配置类、存储库和工作单元类，它们自己不做任何逻辑并依赖于基本实现。在我看来，显然不能对数据访问组件进行单元测试。

根据上述几点，我要求配置团队将数据和访问组件排除在参与代码覆盖率指标之外是否正确？

【问题讨论】：

标签： .net unit-testing sonarqube code-coverage mstest

【解决方案1】：

我不能代表你提到的技术，特别是考虑到你没有提到代码是用什么语言编写的。我的经验是 Java、Objective-C 和 Swift。

根据我的经验，获得 80% 以上的代码覆盖率并不难。特别是如果您可以应用一个好的模拟框架来协助您的测试用例。

如果您的测试覆盖率工具告诉您，尽管执行了构造函数，但您的覆盖率仍为 0%，那么我会建议两件事之一。涉及的类没有被覆盖工具检测，因此没有跟踪执行，或者该工具没有给你带来好的结果。

第一个问题可以通过确保正确检测所有类来解决。第二个问题可以通过放弃你的覆盖工具并获得一个更好的来解决。

无视阶级是一种虚假的经济。这就像声称你已经完成了对房子的吸尘，因为你排除了本周没有使用的房间。你还没有真正完成，那些房间仍然需要吸尘。

【讨论】：

【解决方案2】：

The rule in TDD is "Test everything that could possibly break" Can a getter break? Generally not, so I don't bother to test it. Besides, the code I do test will certainly call the getter so it will be tested.

Junit test for POJO -> 这个链接描述了POJO是否被测试！

基本规则，所有内容都需要在代码库中进行测试。但是 POJO 和自动生成的代码库会有例外。

在这种情况下，这取决于接受报告的团队。使用Exclude from Sonar链接，我们可以排除模块。

1. I presume it won't be accounted for as a covered line for Data component?

取决于负责报告的团队。如何有开放的图书馆来检查这些。 Pojo testing library

2. The Entity framework data component has virtually no business logic...

没有业务逻辑的单元测试毫无意义。在这种情况下，请使用从声纳中跳过的方法。

PS：由于没有提及您使用的语言，因此将其用于 Java - sonar - maven 环境。

【讨论】：