在单元测试的上下文中，什么是“单元”？
我通常通过单个方法将其定义为单个代码执行路径。这是根据经验法则得出的，即测试一种方法所需的单元测试数等于或大于该方法的cyclomatic complexity数。
那并不重要。当然，您要求开始进行单元测试是正常的，但是我重复一遍，这并不重要。
单位是类似：
但是，“单元”，功能或方法，也可以从应用程序调用另一个“单元”，该单元同样由测试执行。因此，“单元”可以跨越多个功能甚至几个类。
“测试比单位重要（testivus）。一个好的测试应该是：
我想说单元测试中的单元是课程的单项职责。
当然，这种意见来自我们的工作方式：
在我们的团队中，术语“单元测试”用于测试单个班级职责的测试。我们使用模拟对象来覆盖所有其他对象，这样，类职责才真正被隔离，如果其他对象中有错误，则类职责不会受到影响。
我们使用集成测试一词来测试两个或多个类如何一起工作，以便我们看到实际的功能。
最后，我们帮助客户编写验收测试，该验收测试将在整个应用程序上运行，以查看当“用户”使用该应用程序时实际发生的情况。
这就是让我认为这是一个很好的描述。
虽然定义可以变化，但是“单位”是独立的代码。
通常，它是单个类。
但是，很少有类单独存在。因此，您通常必须模拟与您的受测类协作的类。
因此，“单元”（也称为“夹具”）是可测试的东西，通常是一个类，以及协作者的模型。
您可以使用单元测试技术轻松测试相关类的包。我们一直在这样做。这些装置中几乎没有模拟物。
实际上，您可以将整个独立应用程序作为单个“单元”进行测试。我们也这样做。提供一组固定的输入和输出，以确保整个应用程序正确执行操作。
单元是可以单独测试的任何元素。因此，几乎总是在OO环境中测试方法，以及在该类的方法之间存在紧密耦合的某些类行为。
根据我的经验，关于“什么是单位”的辩论是浪费时间。
更重要的是“测试速度有多快？”快速测试以100 + /秒的速度运行。缓慢的测试运行得很慢，以至于您每次暂停思考时都不会反身运行它们。
如果测试很慢，您将不会频繁地运行它们，这将使错误注入和错误检测之间的时间更长。
如果测试缓慢，则可能无法获得单元测试的设计优势。
想要快速测试吗？跟随迈克尔·费瑟（Michael Feather）的rules of unit testing。
但是，如果您的测试很快并且可以帮助您编写代码，那么谁在乎它们的标签呢？
我们将'单元'定义为单个类。
正如您正确地断言'unit'是一个模棱两可的术语，当开发人员仅使用表达式而未添加细节时，这会引起混淆。在我工作的地方，我们花了一些时间定义当我们说“单元测试”，“验收测试”等时的意思。当新加入团队时，他们将了解我们的定义。
[从实用的角度来看，关于“单位”的观点可能总是存在分歧。我发现重要的是，该术语在项目的上下文中始终使用。
我在工作'单位'是一项职能。那是因为在我们的设计中，除了功能分解（没有OOP）之外，我们不允许使用其他任何东西。我会100％同意威尔的回答。至少这是我在发动机和飞行控制以及各种其他系统的嵌入式编程工作范式中的答案。
可以是不同的东西。类，模块，文件，...选择所需的测试粒度。
我会说一个单位是一个可以在应用程序中使用的'黑匣子'。它具有已知的接口并提供明确的结果。这是必须根据设计规范进行的工作，并且必须是可测试的。
话虽如此，当我在这种“黑匣子”中构建项目时，我经常使用单元测试作为开发辅助。
我的理解（或基本原理）是，单元应遵循抽象层次结构和类似于代码层次结构分解的范围。
一种方法是一种小的且通常是原子性的（概念上）的操作，处于较低的抽象级别，因此应进行测试
类是提供服务和状态的中级概念，因此应进行测试。
整个模块（尤其是其组件是隐藏的）是具有有限接口的高级概念，因此应该对其进行测试，等等。
由于许多方法和类之间的交互会产生许多错误，因此，在您已经拥有可以利用每种重要组合的方法之前，我看不到只有单个方法才能进行单元测试的方法，但是这表明您没有做到这一点。在编写客户端代码之前，请进行足够的测试。