单元测试时"单位"应该是什么？

Question

今天在Proggit上,我正在阅读一篇题为" 为什么单位测试是浪费时间 " 的提交评论帖.

我并不是真正关心这篇文章的前提,而是关于它的评论:

问题的根源在于商业软件项目中的大多数代码"单位"都是微不足道的.

更改单位的大小,直到它不再是微不足道的？无论如何,谁将代码单元定义为单个函数或方法!

和

好吧,我合作的一些人想要将一个单元定义为单个功能.这完全是愚蠢的.我最喜欢的"单元"定义是:可以有效测试的最小代码片段.

我们是否花了太多时间来模拟一些对象并测试一些简单的代码并没有真正添加任何有价值的东西？

单元测试时"单位"应该是什么？功能级别测试是否过于细化？

Answer 1

引用维基百科似乎微不足道,但我认为在这种情况下它非常简洁和准确:

单元是应用程序中最小的可测试部分.

这似乎与你的问题中的评论一致,即单元是"可以有效测试的代码中最小的部分".换句话说,尽可能地使单元尽可能小,这样它对开发人员/测试人员本身仍然有意义.

通常,您需要单独测试项目的某些部分,然后测试它们如何相互作用.拥有各种级别(级别)的单元测试通常是明智之举,因为它有助于确保您的代码在各个级别上工作,从单个功能到完整的自包含任务.我个人并不认为测试个别功能是错误的,甚至是无益的,只要他们自己做一些有用的事情,通常情况就是如此.

老实说,"单元测试"中没有明确或严格的"单位"定义,这正是使用模糊术语"单位"的原因!学习需要测试的内容以及在什么级别上是经验问题,而且通常只是试验和错误.这可能听起来有点令人不满意,但我相信这是一个合理的规则.

Answer 2

我一直在功能级别上进行测试，而且效果很好。对我来说，最重要的是单元测试可以测试两段代码之间的契约。单元测试仅充当调用者，并确保要测试的代码（无论大小，单个函数或需要30分钟测试的巨大的嵌套库）以可预测的方式返回结果。

单元的整个测试要确保兼容性（不破坏交互作用）并确保可预测的结果。在任何可以交换信息的地方进行测试都将有助于稳定您的应用程序。

更新：每当客户或用户报告严重案例破坏了我的应用程序中的交互时，我也总是添加了单元测试。修复它对我来说是不够的-添加一个单元测试以确保该修复程序能够防止回归，并有助于使一切保持稳定。

Answer 3

对于您的定义， “单位”应该是单个原子单位。也就是说，确切地定义用于单元测试的“单元”是相当主观的。它可能在很大程度上取决于您的体系结构是什么，以及应用程序如何选择分解功能单元。我的意思是，除了您定义的内容外，没有明确定义的“单位”。“单元”可以是具有单一副作用的单一方法，也可以是一组相关的方法，这些方法共同定义了一个单一的，一致的功能集。

在这里，合理性很重要。完全有可能为您拥有的每个类的每个访问器编写单元测试；但是，这显然是过分的。同样，将整个应用程序定义为一个单元是可能的，但是很愚蠢，并且期望有一个测试来测试它。

通常，您需要一个“测试单元”来描述一个清晰定义的功能块。在查看应用程序的每个级别，您都应该能够看到功能的清晰“原子”（如果您的设计不错）。对于低级别的视图，这些操作很简单，例如“从数据库中检索记录”，而在高级视图中，则很简单，例如“创建，编辑和删除用户”。它们也不是互斥的。您可以轻松地将两者作为单元测试。

这里要说明的是，您要测试的单元是有意义的单元。您希望单元测试来验证和验证功能；因此，单元测试所测试的就是您定义的功能。功能单位是什么？这取决于您的个人情况。