显然，I don't understand unit testing .这很好，考虑到我以前从未做过。我正在开始一个新项目，并且想从一开始就将单元测试融入其中，所以我正在学习。
我一直将单元测试与代码覆盖率等同起来，认为你应该有覆盖应用程序中每个函数/方法的单元测试，但显然情况并非如此，我完全误解了这个概念。
所以，
哪些功能从单元测试中受益？ 哪些功能不应该进行单元测试？
我没有完整的答案(老实说，我很想听听任何人的答案)，但至少可以提出几点......
通过首先从测试插入开发，您已经走上了正确的轨道。将单元测试重新安装到现有应用程序中很困难，而且很少能提供真正的好处(相反，通常会产生代码覆盖率的错误感觉)。正确的 TDD 始终是预先考虑的，而不是事后的想法。 我不会费心测试私有(private)功能。各种代码覆盖工具可能会说它未经测试，但如果它是私有(private)的，那么它的功能应该通过测试公共(public)方法来测试。私有(private)方法是内部的，而不是 API 的一部分，类之外的任何东西(甚至测试)都不应该知道或关心它们，因为如果该类的实现发生更改，它们很容易更改。 专注于代码的公开 API。针对您的接口(interface)编写测试，而不是针对您的类。类本身稍后会根据测试实现和测试。 最后，也是非常重要的，研究你在做什么以及它的好处是什么。编写单元测试不是一个即兴即用的过程。通过简单地编写测试并不能实现良好的测试覆盖率，而是通过了解 TDD 以及如何实现它。这需要练习。我会给出的一个建议是做一个适当的 TDD 项目，并尝试将测试 retrofit 到现有项目中。我们可以整天互相告诉对方前者比后者好，但是通过两者都做，您实际上可以辨别差异并更好地理解为什么它更好。这将使您不仅仅是编写测试，而是成为 TDD 专家以及它真正带来的东西。任何人都可以编写测试，但通常他们只是在浪费时间，除非他们真正了解发生了什么。