单元测试应该和不应该包含哪些内容？

Question

显然,我不了解单元测试.这很好,考虑到我以前从未这样做过.我正在开始一个新项目,并希望从一开始就将单元测试融入其中,所以我希望学习.

我一直把单元测试与代码覆盖等同起来,认为你应该有单元测试来覆盖应用程序中的每个函数/方法,但显然情况并非如此,我完全误解了这个概念.

所以,

• 什么样的功能可以从单元测试中受益？
• 什么样的功能不应该进行单元测试？

Answer 1

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

1. 通过首先从测试驱动开发，您已经走上了正确的轨道。将单元测试重新安装到现有应用程序中很困难，而且很少提供真正的好处（相反，通常会给代码覆盖率带来错误的感觉）。正确的 TDD 始终是预先考虑，而不是事后考虑。
2. 我不会费心测试私有函数。各种代码覆盖工具可能会说它未经测试，但如果它是私有的，那么它的功能应该通过测试公共方法来测试。私有方法是内部的而不是 API 的一部分，类之外的任何东西（甚至是测试）都不应该知道或关心它们，因为如果该类的实现发生变化，它们很容易改变。
3. 专注于代码公开的 API。针对您的接口编写测试，而不是针对您的类。类本身稍后会被实现并针对测试进行测试。
4. 最后，也是非常重要的一点，研究你在做什么以及它的好处是什么。编写单元测试不是一个即装即用的过程。不能通过简单地编写测试来实现良好的测试覆盖率，而是通过理解 TDD 以及如何实现它。这需要练习。我给出的一个建议是做一个适当的 TDD 项目，并尝试将测试改造到现有项目中。我们可以整天告诉对方前者比后者好，但通过两者你实际上可以辨别差异并更好地理解为什么更好。这将使您不仅仅是编写测试，而是成为更多的 TDD 专家以及它真正带来的东西。任何人都可以编写测试，但他们往往只是在浪费时间，除非他们真正了解正在发生的事情。

Answer 2

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