在单元测试的背景下，什么是“单位”？
答案 0 :(得分：12)
我通常通过单个方法将其定义为单个代码执行路径。根据经验，测试方法所需的单元测试数量等于或大于方法的cyclomatic complexit y数。
答案 1 :(得分：8)
虽然定义可能有所不同，但“单位”是一段独立的代码。
通常，它是一个单独的类。
但是，很少有类孤立存在。因此，您经常需要模拟与您正在测试的类协作的类。
因此，“单位”（也称为“装置”）是一个可测试的东西 - 通常是一个类加上合作者的模型。
您可以使用单元测试技术轻松测试相关类的包。我们一直这样做。这些灯具中很少或没有嘲笑。
实际上，您可以将整个独立应用程序作为单个“单元”进行测试。我们这样做也是。提供一组固定的输入和输出，以确保整个应用程序正确地完成任务。
答案 2 :(得分：6)
单位是可以单独测试的任何元素。因此，人们几乎总是在OO环境中测试方法，以及在该类方法之间存在紧密耦合的一些类行为。
答案 3 :(得分：2)
根据我的经验，关于“什么是单位”的辩论是浪费时间。
更重要的是“测试有多快？”快速测试以100 + /秒的速度运行。慢速测试运行得足够慢，以至于每次停下来思考都不会反复运行它们。
如果您的测试速度很慢，则不会频繁运行它们，从而使错误注入和错误检测之间的时间更长。
如果您的测试速度很慢，您可能无法获得单元测试的设计优势。
想要快速测试吗？关注Michael Feather的rules of unit testing。
但是，如果您的测试很快并且他们正在帮助您编写代码，谁会关心他们的标签？
答案 4 :(得分：1)
我们将'unit'定义为单个类。
正确地断言'unit'是一个含糊不清的术语，当开发人员只使用表达式而不添加细节时，这会导致混淆。在我工作的地方，我们花时间来定义当我们说“单元测试”，“验收测试”等时我们的意思。当有新人加入团队时，他们会学习我们的定义。
从实际的角度来看，对于“单位”是什么，可能总会存在意见分歧。我发现重要的只是术语在项目的上下文中一致地使用。
答案 5 :(得分：1)
如果我工作'单位'是一个功能。那是因为在我们的设计中我们不允许使用除功能分解之外的任何东西（没有OOP）。我同意Will的回答100％。至少这是我在发动机和飞行控制以及各种其他系统的嵌入式编程工作范例中的答案。
答案 6 :(得分：0)
可以是不同的东西。类，模块，文件，...选择所需的测试粒度。
答案 7 :(得分：0)
我想说一个单位是一个“黑匣子”，可以在一个应用程序中使用。它具有已知的界面并提供明确定义的结果。这是必须根据设计规范工作的东西，必须是可测试的。
话虽如此，我经常在这样的“黑匣子”中建造物品时使用单元测试作为开发辅助工具。
答案 8 :(得分：0)
我想说单元测试中的一个单元是一个单一责任。
当然，这种意见来自我们的工作方式：
在我的团队中，我们使用术语单元测试来测试单个类的职责。我们使用模拟对象来覆盖所有其他对象，以便类职责真正隔离，如果其他对象在其中有错误，则不会受到影响。
我们使用术语集成测试来测试两个或多个类如何一起运行的测试，以便我们看到实际的功能在那里。
最后，我们帮助客户编写验收测试，这些测试在整个应用程序中运行，以查看“用户”使用该应用程序时实际发生的情况。
这使我觉得这是一个很好的描述。
答案 9 :(得分：0)
我的理解（或理由）是单元应遵循抽象和范围的层次结构，类似于代码的层次分解。
一个方法是一个很小的，通常是原子（概念上）操作，处于低抽象级别，因此应该进行测试
一个类是一个提供服务和状态的中级概念，因此应该进行测试。
整个模块（特别是如果其组件被隐藏）是一个具有有限接口的高级概念，因此应该进行测试等。
由于许多错误来自多个方法和类之间的交互，我不知道单元测试只有单个方法如何才能实现覆盖，直到你已经有了使用每个重要组合的方法，但这表明你没有在编写客户端代码之前测试不够。
答案 10 :(得分：0)
这不重要。当然，你要求开始进行单元测试是正常的，但我重复一遍，这并不重要。
该单位的内容如下：
但，“单位”，功能或方法也可以从应用程序中调用另一个“单元”，这同样由测试执行。所以“单位”可以跨越几个函数甚至几个类。
“测试比单位更重要”（testivus）。一个好的测试应该是：