如果我可以使用集成测试,为什么还要打扰单元测试呢？

Question

好吧,我知道我正在做一个像这样的声明,所以我的问题是每个人都说服我,我错了.采取这种情况:

我有方法A,它调用方法B,它们在不同的层中.

所以我单元测试B,结果是null.所以我测试返回null,并且单元测试通过.尼斯.

然后我单元测试A,它期望从B返回一个空字符串.所以我模拟了B层,一个空字符串返回,测试通过.再好一点.(假设我没有意识到A和B的关系,或者可能有两个不同的人在构建这些方法)

我担心的是,在我们测试A和B之前,我们找不到真正的问题,即集成测试.由于集成测试提供了对单元测试区域的覆盖,因此构建所有这些单元测试似乎是浪费精力,这些测试实际上并没有告诉我们任何(或非常)有意义的.

为什么我错了？

Answer 1

这是一篇关于测试分类的文章,其中包含一些参数

一旦我们只是比较单元测试和功能测试,我就不会提到整体测试的好处:

• 单元测试可帮助您缩小发生错误时查看的范围. - 在这种情况下,让我们包括C,D,E,...,Z类.如果您只进行了集成测试并且失败了,那么您从哪里开始寻找？如果你没有单元测试,你需要查看每个类中的每个位置以及它们之间的"连线"(这是一个较窄的范围).如果你有单元测试,那么你只需要检查布线.在这种情况下,没有一些较小的集成测试也是一件坏事,比如只测试A,B,C和D(所以你已经知道它们之间的"连线"是否正常工作).
• 通过单元测试,您可以更快地失败.如果您使用TDD,情况就更是如此.你可能在创建了A级和B级之后编写了测试.当你运行测试时,A和B的工作方式在你的脑海中并不那么新鲜(也许你在前一周写过它们 - 希望你不要开始测试只有当产品"完成"时).然后你必须记住你写这些内容时的想法.此外,单元测试速度更快,因此您更有可能更频繁地运行它们(也许每次保存时都会自动运行它们？)
• 单元测试可以更好地记录您的课程应该如何表现.如果你是"普通程序员",你可能讨厌编写文档.这会强制您在编程时编写文档,并强制文档永远不会过时(如果是,则测试失败).当你需要更改其他人的代码时,它也会有所帮助.

在理想的世界中,当测试失败时,您不需要超过2分钟就能知道要查看的内容(无需调试).进行各种尺寸测试的想法只是实现这一目标的指导原则,而不是花费数小时/天/周调试=).

Answer 2

单元测试不是用于测试集成中应测试的内容 - 它们是互补的测试集.单元测试保证给定的代码单元自己执行它的设计,而不是其他任何东西.集成测试可确保所有单元协同工作,以执行总体要求.

Answer 3

单元测试更细粒度,允许您查明错误.如果A或B失败怎么办？如果集成测试失败,您怎么知道哪一个失败了？这只是两种方法 - 想象一下,如果你是集成测试Web应用程序的前端控制器,它会加载一些模型并调用一堆方法.这将是一场噩梦,试图找出究竟出了什么问题.

Answer 4

好的，单元测试不会找到所有问题，这就是为什么我们也有集成测试！

但是，假设您有一个方法必须返回一个介于1到9之间的值，并且为它编写了一个测试，然后发现它返回的值为null或10，那么您就知道在进行集成测试之前代码已被破坏。

Answer 5

我认为主要原因是:

1:单元级测试为您提供有关失败的更多信息.

2:在集成组件之前,您无法运行集成测试.越早发现错误,修复就越容易/越便宜.

Answer 6

集成测试遭受某种形式的组合爆炸：假设方法 A 有 5 种不同的行为方式（不同的边缘情况等），方法 B 也是如此。如果您一起测试它们，理论上现在有 25 种不同的情况去测试！是的，其中许多最终可能是相同的，或者由于某种原因而不能发生，但基本上，一起测试的东西越多，测试所有边缘情况就越不可能。