单元测试定义-范围和模拟外部依赖项

Question

我对重新定义单元测试的定义感到困惑。
我认为单元测试是关于模拟外部依赖关系的，范围可能像IT测试一样大（不止一个类）。 通过这种思维方式，我可以在UT完整流程中进行测试，这可以帮助我快速捕获错误（我不使用Spring，没有使用外部依赖项），我想快速捕获错误，因为如果在进行重构时，我想每隔几分钟运行一次测试，看是否有损坏的东西，因此我需要快速运行测试。 （这就是为什么我只想运行UT而不是IT测试的原因）。

在行业中，当谈论UT时，UT应该很小 （范围），并且还要模拟外部依赖关系。 我认为这不是一个好方法，因为这意味着我的UT可能会错过IT捕获的错误，这意味着每隔几分钟仅运行UT是不够的，我应该运行速度较慢的IT测试，对我不利，因为重构过程将花费我更长的时间。

那我想念什么呢？ 为什么不编写像IT一样测试完整流程但模拟外部依赖关系的UT？ 谢谢

Answer 1

通常，单元测试是涵盖单个类的单个方法的测试。

在面向对象的编程中，一个单元通常是一个完整的接口，例如一个类，但可以是一个单独的方法（ https://en.wikipedia.org/wiki/Unit_testing ）

一个区别是人们认为是一个单位。 面向对象的设计倾向于将类视为单元，过程或功能方法可能会将单个功能视为单元。 但这确实是一种情况，团队出于对系统及其测试的理解而决定成为一个单元是有意义的。 尽管我从单元是一类的概念开始，但我经常采用一堆紧密相关的类并将它们视为一个单元。 我很少将类中方法的子集作为一个单元。 但是，您定义它并不重要（ https://martinfowler.com/bliki/UnitTest.html ）

通常，您的单元测试涵盖一小段代码，而集成测试则用于测试多个类/模块之间的集成。 与IT测试相比，您运行单元测试的频率要高得多。

小型单元测试的目的是尽可能地找出导致错误的代码段。 如果使用多个类的It测试失败，则需要逐个检查所有这些类以查找问题。 但是，如果涵盖单个类的单个方法的单元测试失败，那么您将确切知道问题出在哪里。

Answer 2

定义：单元测试是一种测试方法，旨在发现或防止那些小的（甚至最小的）孤立软件的测试可以检测到的错误。

该定义为单元测试的范围设置了下限，即从最小的软件开始。 对于上限，它留有一定的自由度。 有时人们试图通过提出单位一词的定义来划定上限。 但是，我不太在乎什么是单位。 取而代之的是，我根据被测试软件的大小可以设定为问题的上限，以便仍然可以合理地应用单元测试方法。

例如：一个功能，例如15行代码，将进行单元测试。 但是，如果我重构我的代码，以便从该函数中提取两个辅助函数，该怎么办？ 根据定义，我现在还可以将单元测试应用于助手功能。 但是，如果我已经有了一套完善的单元测试套件，那么它们仍然可以与原始功能的界面一起使用。 因此，我可以保留测试，而忽略更改后的内部结构-仍然是单元测试。

另一个示例：在C ++中，容器类与相关的迭代器类一起出现。 容器类及其对应的迭代器类紧密耦合。 与单元测试方法一起测试这些类在许多情况下都可以很好地工作。 在测试迭代器时，通常不会将其与容器类隔离开来，而是将它们一起测试-而且我仍然认为这是单元测试。

摘要第1部分：只要应用单元测试方法有意义，您还可以将其应用于紧密耦合的函数集甚至紧密耦合的类。

再次看上面的定义，它提到隔离。 但是请注意，此处的隔离用于对可以发现的错误的类型进行分类：单元测试用于发现可以在隔离的软件中找到的错误。 它并没有说明您实际上必须在测试期间隔离代码。 换句话说，您不必模拟依赖关系。

模拟是有原因的。 如果您考虑对函数或方法进行模拟，则应该知道要解决的问题。 如果没有问题要解决，请不要嘲笑。 例如，您也不要模拟诸如sin或cos之类的标准库数学函数，因为它们在大多数情况下也不会引起问题。

例如，如果组件依赖（DOC）导致不确定的行为（随机性，时间等），您将进行模拟。 但是，使用模拟程序时，您找不到那些错误，这些错误与对被测函数与DOC的相互作用应如何工作的误解有关：由于实施了模拟程序，因此要根据潜在的误解来实现它们。 这不是单元测试的缺陷：这仅仅是为什么除了单元测试之外还需要集成和系统测试的原因。

总结部分2：单元测试不一定是关于模拟的。 它着重于发现一种特殊的错误： 如果代码是孤立的， 则可以找到。 这使所有其他错误（尤其是只能在集成软件中找到的错误）不在单元测试的范围内。