Java 如果一个方法已经被另一个测试覆盖，那么为它编写附加测试有意义吗？

我正在用单元测试测试我的spring boot应用程序，在覆盖率报告中，我有+85%的分支覆盖率。有些情况下，在测试其他方法（如映射器、实用方法等）时，会涉及一些方法

例如，在服务方法中，我调用了mapper和utility方法，这些方法在覆盖率报告中被标记为coverage，因为我测试了该服务方法

---

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

我通常采用一种不同的方法，希望与大家分享

比如说，我是一名开发人员，有任务创建映射器或实用程序。 此时该服务甚至不存在

我写代码，但我想检查自己。所以我对它进行了单元测试。我现在不关心覆盖率，对我来说，覆盖率是一个工具，可以帮助我理解并决定我是否已经完成了所有需要的检查，或者我在我编写的映射程序代码中遗漏了一个可能有bug的区域

因此，我已经确保我的代码是完美的，我提交它，并转移到另一个任务

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

因此，您基本上不关心映射代码，而是假设它可以工作。然而，您确实希望检查您的服务，因此您编写了单元测试，可以模拟Mapper上的依赖关系，或者在测试中运行它，如果它不是真正的依赖关系，并且速度很快，等等。同样，您不关心总体覆盖率，您关心的是您的代码，您希望确保您的代码没有bug，而且，覆盖率帮助您确保在代码达到生产要求之前，您已经尽了最大努力检查代码

至于我以前对Mapper的测试，它们仍然在运行

总之，我认为代码不应该为了覆盖而被覆盖，但是如果您愿意，测试（和覆盖）应该为您提供一个安全网

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

另外，我相信对此可能有很多不同的观点，所以这个问题没有一个单一的正确答案

不要为“封面代码”编写单元测试。
编写单元测试以验证行为。
执行特定生产代码行的测试数量没有任何意义

---

此外，单元测试还可以对单元（任意代码段）进行隔离测试。这意味着，如果被测代码使用其他单元作为依赖项，那么在单元测试期间，这些其他单元应该被测试双精度（例如存根、伪代码或模拟代码）替换。

当然可以。单元测试不仅仅是为了覆盖。覆盖范围是其中的一部分。您的主要目标是编写单元测试，以避免或最小化来自测试人员或生产的bug。 您应该使用所有类型的负面场景和正面场景来测试您的功能。

---

除此之外，还应该测试代码的边界条件

嗯~如果你的一个方法失败了-你能从你的方法中分辨出哪个失败了吗？不，如果服务方法测试失败了，我不知道是不是因为实用性，单元测试应该测试每个单独的单元或组件，所以我认为最好尝试为单独的方法编写单元测试，然后测试您的服务方法。双重保险比偷工减料更“安全”。但是，您仍然比那些不进行单元测试的人做得好85%。）我同意你应该“测试它”。如果另一个测试碰巧“覆盖它”，对我来说这是巧合。对于每一件事，你都应该有测试来充分地运用它，并且明确地与它相关。如果一段特定的代码因此被多次“覆盖”，那没关系。“在某些情况下，某些方法在测试其他方法时被覆盖”——你应该模仿那些你认为被覆盖的方法。假设您正在测试其他方法，但由于“覆盖”方法而失败。同时测试两者将测试它们的集成，而不是单元本身。