什么时候测试不是单元测试？

Question

我正在寻找以下规则:

如果出现以下情况,则测试不是单元测试:

那里还有什么？

Answer 1

在以下情况下,测试不是单元测试:

它与数据库进行对话

它通过网络进行通信

它触及文件系统

它不能与任何其他单元测试同时运行

您必须对您的环境执行特殊操作(例如编辑配置文件)才能运行它.

当然不是.跨越多个层的测试(例如业务逻辑,视图和控制器)也不被视为单元测试. (13认同)
我不认为特征列表是定义概念的有用方法.它减少了对一堆规则和琐事的理解.虽然初学者自然渴望规则 - 包括我自己,而且我是单元测试的初学者 - 从长远来看,关注概念,为什么重要,然后尝试和思考它如何适合您自己的环境更有效.因此,当初学者要求规则时,关心的专家应该首先解释这个想法,然后列举一些例子.:) (6认同)
-1这个答案只是"教条".一个更有用的定义将导致开发人员创建良好的,有用的*自动化测试,而不是仅仅尝试适应任意标准.关于触摸文件系统,特别是点,鼓励开发商尝试和*模拟*文件系统了,它通常是相当难以在实践中做的; 此外,IO代码倾向于使用低级API,因此该代码特别针对特定于实现; 确实让测试*触摸*(本地)文件系统要好得多. (2认同)

Answer 2

如果测试不是单元,则测试不是单元测试.

说真的,这就是它的全部.

单元测试中"单元"的概念没有明确定义,事实上,到目前为止我发现的最佳定义实际上并不是一个定义,因为它是循环的:单元测试中的一个单元是最小的可能的东西,可以单独测试.

这为您提供了两个检查点:它是单独测试的吗？它是最小的可能吗？

请注意,这些都与上下文有关.在一种情况下可能是最小的可能(例如,整个对象)可能在另一种情况下只是一个单一方法的一小部分.在一种情况下,隔离可能是另一种情况(例如,在内存管理的语言中,您永远不会与垃圾收集器隔离运行,并且大部分时间都不相关,但有时可能不是).

Answer 3

它没有断言,并且不期望抛出异常.

不是100%同意.您可以进行测试,只测试一些代码运行而不抛出异常.它并不理想,但有时甚至比什么都没有.你可以说总是有一个隐含的断言,被测单元不会抛出异常. (5认同)
它默默地传递.你可以在某些IDE中做的是调整默认的单元测试模板,以包含一个`Assert.Fail()`或等价的测试方法的最后一行.这样,它将"默认失败" (2认同)

Answer 4

困难的......

对于我一个单元测试验证在一个特定的逻辑块隔离.意思是,我采取一些逻辑,从其余部分提取它(如果有必要通过模拟依赖关系)并通过探索不同类型的可能控制流来测试该逻辑 - 一个单元(整体).

但另一方面......我们总能100%说正确或不正确吗？不要成为哲学,但是 - 正如迈克尔在他的帖子中所说:

做这些事情的测试也不错.通常它们值得写作,它们可以用单元测试工具编写.但是,能够将它们与真正的单元测试分开是很重要的,这样我们就可以保留一组测试,每当我们进行更改时,我们都可以快速运行这些测试.

那么为什么我不应该编写一个单元测试,通过从我的测试文件夹中的文件系统访问一些虚拟文件来验证解析例如xls文件的逻辑(就像MS测试允许使用DeploymentItem一样)？

当然 - 如上所述 - 我们应该将这些测试与其他测试分开(可能在JUnit中的单独测试套件中).但是我觉得如果他觉得把它们放在那里也应该写下那些测试......然后再一次记住单元测试应该只是单独测试一块.

在我看来,最重要的是这些测试运行速度快,并且不需要太长时间,因为它们可以反复且经常运行.

Answer 5

在以下情况下,测试不是单元测试:

良好单元测试清单:

一些更好的实践(没有特别重要的顺序):

这是我从Roy Osherove的书 - 单元测试艺术中提取的知识的一部分