如果一个方法已经被另一个测试覆盖，那么为一个方法编写附加测试是否有意义？答案

【问题标题】：Does it make sense to write addition test for a method if it is already covered by another test?如果一个方法已经被另一个测试覆盖，那么为一个方法编写附加测试是否有意义？
【发布时间】：2019-12-03 14:38:05
【问题描述】：

我正在使用单元测试和覆盖率报告测试我的 Spring Boot 应用程序，我的分支覆盖率 +85%。在某些情况下，在测试其他方法（例如映射器、实用程序方法等）时会覆盖某些方法。

例如，在服务方法中，我调用了映射器和实用程序方法，这些方法在覆盖率报告中被标记为已覆盖，因为我测试了该服务方法。

我的问题是，为这些映射器和实用程序方法编写额外的测试是否有意义，因为它们已经包含在服务测试中？

【问题讨论】：

好吧~如果你的一种方法失败了——你能从你的方法中分辨出哪种方法失败了吗？
不，如果服务方法测试失败，我不知道是因为实用程序，映射器还是一些内联逻辑。
单元测试应该测试每个单独的 unit 或组件 - 所以我会说最好尝试为单独的方法编写单元测试 - 然后让你的服务方法测试。双重覆盖将比偷工减料“更安全”。但是，您仍然比那些不进行单元测试的人好 85%。 :)
我同意你应该“测试它。”如果另一个测试恰好“覆盖它”，对我来说那是巧合。对于每一件事，你都应该有充分地运用那件事并且与那件事明确相关的测试。如果一段特定的代码因此被多次“覆盖”，那很好。
"在某些情况下，某些方法在测试其他方法时会被覆盖" - 你应该嘲笑那些你认为被覆盖的人。想象一下，您正在测试那些其他方法，并且由于“覆盖”方法而失败。一起测试两者将是测试它们的集成，而不是单元本身。

标签： java unit-testing test-coverage

【解决方案1】：

我通常会采取不同的方法来分享。

假设，我是一名开发人员，任务是创建一个映射器或实用程序。目前该服务甚至不存在。

我编写了我的代码，但我想检查一下自己。所以我对它进行单元测试。我现在不在乎覆盖率，对我来说，覆盖率是一种工具，可以帮助我理解和决定我是否已经完成了我需要的所有检查，或者我错过了 Mapper 代码中的一个区域，我写的可能有bug。

所以我已经确保我的代码是完美的，然后我提交它并转移到另一个任务......

稍后（几周、几个月、几年）某人，我或其他程序员，创建了一个使用我的代码的服务。例如，让我们假装是你。

所以你基本上不关心映射代码，你假设它可以工作。但是，您确实想检查您的服务，因此您编写了可以模拟对 Mapper 的依赖关系的单元测试，或者如果它不是真正的依赖关系并且它的快速和一切都在测试中运行它。同样，您不关心整体覆盖率，您关心您的代码，您想确保您的代码没有错误，并且再次，覆盖率可以帮助您确保您已尽最大努力检查您的代码在它满足生产之前。

至于我对 Mapper 的旧测试 - 嗯，它们仍在运行。

底线我不认为应该为了覆盖而覆盖代码，但如果您愿意，测试（和覆盖）应该为您提供安全网。

考虑到这一点，您应该为您的代码编写测试，如果您可以模拟其他依赖项，如果不能，请运行它们。

附：我相信可能会有很多不同的意见，所以这个问题没有一个正确的答案

【讨论】：

【解决方案2】：

不要编写单元测试来“覆盖代码”。
编写单元测试来验证行为。
执行某行生产代码的测试次数没有任何意义。

单元测试也可以单独测试一个单元（一段任意代码）。这意味着如果 被测代码 使用其他单元作为 依赖项 这些其他单元应该被 test doubles 替换（例如存根、伪造或模拟) 在单元测试期间。

【讨论】：

【解决方案3】：

当然可以。单元测试不仅仅是为了覆盖。覆盖范围是其中的一部分。您的主要目标是编写单元测试以避免或最小化来自测试人员或生产的错误。您应该使用各种负面情景和正面情景来测试您的功能。除了这些你应该测试你的代码的边界条件。

【讨论】：