单元测试定义-范围和模拟外部依赖项 [英] Unit test definition - Scope and Mocking external dependencies

问题描述

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

I have a confusion regrading the definition of unit test.
I think unit tests is about mocking external dependencies, the scope can be large like IT test (more than one class). In this way of thinking, I can test in my UT complete flow and that can help me catch bugs fast, (I'm not using Spring, I'm not using external dependencies), I want to catch bug fast because if I'm doing refactoring, I want to run my tests every few minutes to see if something's broken so I need my tests to run fast. (That's why I only want to run UT and not IT tests).

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

It seems that in the industry, when talking about UT, UT should be small (scope), and also mock external dependencies. I don't think this is a good way of thinking, because that means that my UT can miss bugs that IT catches, which means that running only UT every few minutes is not good enough and I should run IT tests which is much slower which is not good for me because the refactoring process will take me much longer.

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

So what Am I missing something? Why not to write UT that tests complete flows just like IT but with mocking of external dependencies? Thanks

推荐答案

定义:单元测试是一种测试方法，旨在发现或防止那些可以通过对小型(甚至最小的隔离软件.

Definition: Unit-testing is the testing method that aims at finding or preventing those bugs which are detectable by the testing of small (even minimally small) isolated pieces of software.

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

This definition sets the lower bound for the scope of unit-testing, namely starting from the smallest pieces of software. For the upper bound it leaves a degree of freedom. Sometimes people try to also delimit the upper bound by coming up with definitions for the term unit. But, I do not care so much what a unit is. Instead, I set the limit based on the question how big the software piece under test can be such that the unit-testing methods still can be applied sensibly.

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

For example: A single function of, say, 15 lines of code would be subject to unit-testing. But, what if I refactor my code such that from the function two helper functions are extracted? According to the defintion I could now also apply unit-testing to the helper functions. But, if I already had a perfect suite of unit-tests, these should still work with the original function's interface. Thus, I could keep my tests and ignore the changed internal structure - and it would still be unit-testing.

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

Another example: In C++, container classes come together with related iterator classes. The container class and its corresponding iterator classes are tightly coupled. Testing these classes jointly with unit-testing methods will work nicely in many cases. When testing the iterator, you would normally not isolate it from its container class, but rather test both together - and I still consider this to be unit-testing.

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

Summary part 1: As long as applying unit-testing methods makes sense, you can also apply it to sets of tightly coupled functions and even tightly coupled classes.

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

Looking at the above definition again, it mentions isolation. Note, however, that isolation here is used to classify the type of bugs that can be found: Unit-testing is for findings bugs that can be found in the isolated software. It does not state that you actually have to isolate the code during testing. In other words, you do not necessarily have to mock the dependencies.

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

Mocking should be done for a reason. If you consider mocking a function or method, you should know which problem you are about to solve. If there is no problem to solve, don't mock. For example, you also don't mock standard library math functions like sin or cos, because they also don't cause problems in most cases.

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

You would do mocking, for example, if the depended-on-component (DOC) causes non-determinstic behaviour (randomness, time, ...). With mocks, however, you can not find those bugs, which are related to misconceptions about how the interaction of the function under test with the DOCs should work: Since you implement the mocks, you implement them based on your potential misconceptions. This is not a flaw of unit-testing: It is just the reason why in addition to unit-testing you also need integration and system testing.

摘要第2部分:单元测试不一定是关于模拟的.它着重于发现一种特殊的错误:如果代码是孤立的，您可以找到这些错误.这使所有其他错误(尤其是只能在集成软件中找到的错误)不在单元测试的范围内.

Summary part 2: Unit-testing is not necessarily about mocking. It is about focusing on finding a special kind of bugs: Those you could find if the code was isolated. This leaves all other bugs (and especially those you can only find in the integrated software) out of the scope of unit-testing.

这篇关于单元测试定义-范围和模拟外部依赖项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！