Unit testing 什么应该，什么不应该'；t、 单元测试包括哪些内容？

显然。考虑到我以前从未做过，这很好。我正在启动一个新项目，希望从一开始就将单元测试融入其中，所以我希望学习

我一直将单元测试与代码覆盖率等同起来，认为应该有单元测试来覆盖应用程序中的每个函数/方法，但显然不是这样，我完全误解了这个概念

所以

• 什么样的函数从单元测试中受益
• 哪些函数不应该进行单元测试

---

根据TDD（测试驱动开发）方法，人们应该测试每个公共功能，以及该功能中的每个执行路径。

单元测试是一种工具，关于如何使用它有很多方法。我的做法如下：

我针对服务和DAO签名编写单元测试，而不是针对DTO和实体类型编写单元测试。大多数值类型将被间接测试。但是，应该测试DTO和实体类型中的equals和hashCode方法

---

我使用带有模拟依赖项的纯单元测试和带有完整后端的集成测试。要获得适当的报道，两者都需要。

我没有一个完整的答案（老实说，我很想听到任何人这样做），但至少可以抛出几点

通过从测试开始推动开发，您已经走上了正确的轨道。将单元测试重新装配到现有的应用程序中是困难的，并且很少提供真正的好处（相反，通常会给代码覆盖率带来错误的感觉）。正确的TDD总是经过深思熟虑，而不是事后思考

我不会费心去测试私有函数。各种代码覆盖工具可能会说它没有经过测试，但是如果它是私有的，那么应该通过测试公共方法来测试它的功能。私有方法是内部的，不是API的一部分，类之外的任何东西（甚至测试）都不应该知道或关心它们，因为如果类的实现发生更改，它们很容易更改

关注代码中公开的API。针对接口而不是类编写测试。这些类本身后来被实现并根据测试进行测试

最后，也是非常重要的一点，研究你在做什么以及它的好处是什么。编写单元测试不是一个简单的过程。简单地编写测试并不能获得良好的测试覆盖率，但需要理解TDD以及如何实现它。这需要练习。我的一个建议是做一个适当的TDD项目，并尝试将测试重新装配到现有项目中。我们可以整天告诉对方，前者比后者好，但通过两者的结合，你实际上可以辨别出差异，更好地理解为什么它更好。这将使您不仅仅是编写测试，而是成为TDD的专家，以及它真正带来的东西。任何人都可以编写测试，但通常他们只是在浪费时间，除非他们真正了解发生了什么

我一直将单元测试与代码覆盖率等同起来

这并非完全错误。单元测试/任何其他类型的测试自动化只有一个真正不可否认的好处，在100%的情况下都适用：它们实际上运行代码，也就是说，它们覆盖了代码。编译器不运行代码。静态代码分析不运行代码。显然，阅读代码并不能使其运行。自动测试会运行代码（以及手动调试）

任何其他声称的好处都是潜在的，完全取决于编写测试的人的能力和最佳意图

认为你应该有单元测试来覆盖每一个 应用程序中的函数/方法，但显然不是这样

正确，并不是每一行代码都值得在构建期间自动运行

所以

• 什么样的函数从单元测试中受益
• 哪些函数不应该进行单元测试

考虑到上述情况，至少应满足两个条件：

• 无法静态消除错误的可能性（尝试以使无效状态和场景无法表示的方式设计代码，并将自己从大量的单元测试中拯救出来）

• 出错的可能性不低，例如代码不平凡/非常内聚等

或

这是一个任务关键组件/部署错误会带来可怕的后果。在这种情况下，成为一个偏执狂是值得的，即使出错的可能性极低

或

代码是已发布/外部可见合同的一部分，例如库接口。在这种情况下，即使是原始的重言式测试也很有用，因为它们充当可执行的需求/保护您免受已发布合同的无意更改（类似于之前一系列关键任务测试的特定情况）

或

编写测试实际上比手动获取此代码更容易，在大型大型单片计算机中也同样如此。这并不意味着您必须永远保留测试，如果它需要大量维护成本，您可以稍后删除它。当然，在部署之前，代码必须运行，结果必须至少被观察和接受一次

---

以上是真实的，就我目前所知，只要一个人的首要任务是务实。如果优先考虑的是为草率的工作找好借口，那么目标是100%的覆盖率，其他宗教测试实践是完全合理的（想想“这不是我的错-所有测试都是绿色的！”）

但控制器和路由器（即前端控制器）等东西是公开的，我不知道单元测试如何覆盖它们。这就是我在相关问题中提出的问题，也是这个问题存在的理由。是否应该将其修改为“每个返回值的公共函数”，或者是