【问题标题】:Should I write integration test or unit test?我应该编写集成测试还是单元测试?
【发布时间】:2010-01-04 10:10:46
【问题描述】:

我有一个功能可以将照片(存储在数据库中,应用程序为用户提供保存在目录中的选项)保存到给定目录。现在,这不能正常工作。我刚刚修复它。现在,我应该编写单元测试还是函数的集成测试?

【问题讨论】:

  • 我更喜欢为单个类编写单元测试和(有时)为集成测试编写记录工具。

标签: automated-tests


【解决方案1】:

对于您的情况,您想编写一个集成测试来涵盖您提到的场景。我有一个full post on this topic。但是,以下是针对您的问题的摘要版本:

在他的书单元测试的艺术中,Roy Osherove 描述了一个关键原则,即单元测试必须是“可信赖的”。从表面上看,这似乎相当明显。然而,这个底层突出了单元测试与集成测试之间的一些关键区别。

通过值得信赖的测试,您必须能够 100% 地信任结果。如果测试失败,您需要确定代码是否损坏并且必须修复。您不必问诸如“数据库是否关闭?”、“连接字符串是否正常?”、“存储过程是否已修改?”之类的问题。通过提出这些问题,表明您无法相信结果,并且您的“单元测试”可能设计不佳。

由于您的场景描述了具有相似的多个依赖项的情况,您希望通过集成测试来涵盖它。同样,有关更多详细信息,请参阅my full post here

祝你好运!

【讨论】:

  • 感谢您的评论。罗伊的概念当然也帮助了我。也欢迎使用 *!
  • 只需阅读此答案,它也完全回答了我的问题。我对“专业”开发有点陌生,这让我对什么是集成测试有了更好的了解,这是我不太了解的。谢谢!
【解决方案2】:

集成测试和单元测试有不同的范围和目的:

  • 单元测试测试独立于程序其余部分的小段代码(如函数),理想情况下涵盖所有可能的边缘情况(如异常、空参数等)
  • 集成测试从用例的角度测试整个应用程序。它们永远无法涵盖所有​​边缘情况,但它们可以发现代码部分和将它们连接在一起的胶水代码之间的交互问题,而单元测试经常会忽略这些问题

对于一个单一的功能,你真的只能有一个单元测试,你应该这样做。但是你也可以有一个集成测试,显示当用户按下某个按钮时,一张照片会写入目录中,并且也可以在程序中打开。

【讨论】:

    【解决方案3】:
    • 集成测试可帮助您验证是否您的软件正常工作
    • 单元测试可帮助您找出为什么您的软件崩溃

    单元测试在某种程度上也有助于第一个目标。此外,它还有几个优点:

    • 编写运行范围小得多的单元测试通常要便宜得多。
    • 使用单元测试比集成测试更容易覆盖组件状态的组合爆炸。假设您有一个涉及三个组件的设置。他们每个人都有3个不同的状态。然后集成测试整个设置将涉及检查 3 * 3 * 3 = 27 个条件。对单个组件进行单元测试需要测试 3 + 3 + 3 = 9 个条件。 (这过于简单化了,但希望您能明白这一点。)

    因此,单元测试通常比集成测试更受欢迎。但是,您确实不能没有集成测试。集成测试应该是接受您的软件的基石。进行单元测试只是证明你有一堆东西在做something。集成测试证明您拥有工作软件

    【讨论】:

      【解决方案4】:

      有些人会将 DAO 的测试称为集成测试;其他人会说这是一个单元测试。

      不管你怎么称呼它,我想说你应该对所有 DAO 功能进行单元测试,并对用例中体现的前后行为进行集成测试,即“让用户选择保存到文件系统。”我会对这两种情况进行集成测试,因为听起来这两种情况在您的系统中都是可能的。

      【讨论】:

        【解决方案5】:

        我认为这取决于您的问题的根源。 如果函数本身在不同的场景中可能存在一些问题,您可以进行单元测试以在您的函数上测试这些场景。 如果您的功能和程序的其他部分的集成可能会导致一些问题,您应该考虑进行集成测试。 有时像你这样的函数可能需要一些外部资源来完成它的工作,进行一些单元测试来看看如果其中一些资源不可用会发生什么并不是一个坏主意

        【讨论】: