单元测试与代码覆盖率有何关系？

Question

我知道代码覆盖率是一个度量标准，但是有关单元测试的文章经常提到这一点。 但是在设计单元测试时，我试图为我的业务逻辑编写测试，并且不太在意覆盖范围。 那是什么关系呢？

Answer 1

思路如下：

如果运行单元测试时执行的代码涵盖了测试类（被测系统，SUT）中的所有代码，那么显然您已经测试了所有相关代码。
因此，SUT的高代码覆盖率是一件好事。

但这也会产生误导。 拥有100％的代码覆盖率并不意味着您实际上已经测试了所有业务逻辑。 因此，专注于测试所有业务逻辑实际上是更好的方法。
如果您测试了所有业务逻辑，那么您将具有100％的代码覆盖率-或业务逻辑中不需要的某些代码。
不过，您仍然可以使用代码覆盖率来检查您是否实际上已经测试了所有业务逻辑。

因此，总结一下：

1. 如果您没有100％覆盖SUT的代码，则强烈建议您尚未测试完整的业务逻辑
2. 但是：100％的代码覆盖率不能确保您测试了所有逻辑

Answer 2

从字面上看，“单元测试”测试单个单元，换句话说就是单个组件。 因此，单元测试不一定涵盖业务需求，而是确保组件的每个部分都能达到预期的目的。 代码覆盖率衡量的是经过测试并经过验证的代码所占的百分比。 每个未经测试的代码都可能包含缺陷，因此需要较高的代码覆盖率结果。

当然，单元测试，或者更确切地说，用于实施单元测试的框架也可以用于一次测试多个组件。 这些测试虽然很低，但更像集成测试。

代码覆盖率和集成（或业务逻辑测试）之间的关系是，如果您的代码覆盖率是100％，则您将知道每个组件都可以完成应有的功能。 但是，如果您想确保应用程序能够完成应做的工作，那么高的代码覆盖率还远远不够：对于此附加的集成测试（一次测试多个组件）是必需的。

Answer 3

具有代码覆盖率的单元测试可能是一个非常强大的工具。

例如。 测试方法时，可以查看是否已触及所有逻辑路径。 如果不是，则需要更多测试。 如果不可能碰到一段代码，您知道可以删除它而没有任何副作用。