我通常会采用一种我想分享的方法。

说，我是一位开发人员，负责创建Mapper或实用程序。 目前，该服务甚至不存在。

我编写了代码，但随后我想检查一下自己。因此，我对其进行单元测试。我现在不关心覆盖范围，对我而言，覆盖范围是一种工具，可以帮助我了解并确定我是否已进行了所有需要的检查，还是错过了Mapper代码中的某个区域写道可能有一个错误。

所以我确保我的代码是完美的，然后提交并转到其他任务...

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

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

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

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

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

P.S。我相信对此可能会有很多不同的看法，因此对于这个问题没有一个正确的答案

请勿将单元测试写入“覆盖代码”。
编写单元测试以验证行为。
执行某一行生产代码的测试数量没有任何意义。

单元测试也隔离测试一个单元（任意代码）。这意味着如果被测代码使用其他单元作为依赖项，则应将这些其他单元替换为 test doubles （例如存根，伪造品或嘲笑品） ）在单元测试中。

当然可以。单元测试不只是覆盖范围。覆盖率是其中的一部分。您的主要目的是编写单元测试，以避免或最小化测试人员或生产中的错误。 您应该使用各种负面情况和正面情况来测试您的功能。 除此之外，您还应该测试代码的边界条件。