单元测试还是集成测试,为什么要反对?

每周写一篇博客文章需要大量灵感。 幸运的是,Twitter在那里。

这次,是以下推文引发了大火。

虽然我知道Twitter并不是微妙而复杂的想法的发源地,但我相信这种方法弊大于利。 鉴于我将大部分时间用于思考,设计和编写各种测试,因此我相信我的观点可以为您带来一些帮助。

无耻的插件在您学习它的同时,请阅读我的《 Trenches集成测试》一书,该书专门介绍,猜测集成测试。

根据定义,一条推文并不意味着提供支持某人观点的详细论据。 因此,让我们检查一下原始帖子中的声明。

定义

就像在帖子中一样,由于单元的范围,我发现“单元测试”一词不明确。 同样,术语“集成测试”可以指不同人头脑中的不同事物。

在本文的其余部分,我将遵循本文中提出的术语。

达成一致非常重要:在“ Google如何测试软件”一书中,作者使用测试的执行速度对测试进行分类(小,中,大)。在我的书中,我将两个术语保持原样,但明确定义其含义。

“重构的安全网”

设计正确的功能测试可提供全面的代码覆盖范围,并且无需重写,因为它们仅使用公共API。 尝试重构仅具有单类测试的系统通常很痛苦,因为开发人员通常必须同时完全重构测试套件,从而使安全网无效。 这会激发黑客入侵,增加技术债务

我完全同意有关测试公共API的第一部分。

第二部分则更加细微: “尝试重构具有单类测试的系统通常很痛苦。”

这是很合理的。 如果您仅有的测试是单类测试,则重构将破坏这些测试。 在这种情况下,您不知道重构是否引入了回归。

“测试端到端行为”

仅在单类测试中,如果模块之间的接口发生故障,则测试套件可能会通过,但功能可能会失效。 功能测试将验证端到端功能行为并捕获这些错误。

那里有一个重要条件: “仅进行单类测试”

是的,仅由单一类测试组成的测试工具无法确保整个系统按预期工作。

在进行有关测试的演示时,通常使用以下比较:让我们考虑一下汽车的制造。 单级测试类似于分别测试每个螺母和螺栓。 试想一下,对此类组件的测试没有发现任何问题。 但是,如果没有制造原型并将其发送给试驾,则大规模生产汽车仍存在很大的风险。

“写更少的测试”

功能测试通常比单类测试覆盖更大的系统容量

同样,没有什么不同之处。

不过,我发现该声明有些奇怪,因为这并不是真正的优势。 尽管您编写的功能测试较少以涵盖与单类测试相同的范围,但它们却变得更大。

测试的规模是功能测试中的一个问题,因为在测试失败的情况下,很难确定根本原因。 测试范围越大,分析就越困难,有关更多详细信息,请参见下一部分。

“我的功能测试坏了,它比单类测试更难调试。”

想一想如果客户报告新错误,您将花费多少时间。 首先,您花时间尝试重现该错误。 接下来,您必须调试并解决问题。 最后,您必须编写单类测试。 通常,仅重现该错误将比调试功能测试花费更多的时间。 实际上,如果您在调试经过适当设计的功能测试时遇到问题,则实际上与调试整个服务器相同,如果您在调试服务器时遇到问题,我们断言您会遇到更大的问题。

在这一点上,我开始不同意。

首先,我认为不能在功能测试中捕获生产错误。 如果真是如此,那么为什么在生产系统中允许该错误,而在部署之前却未修复该错误?

然后,有一个大胆的声明: “如果您在调试正确设计的功能测试时遇到麻烦” 这看起来像是没有真正的苏格兰人逻辑上的谬误。 因为如果我在调试功能测试时遇到问题,那么作者可以随时回答设计不当的问题。 但是,他没有提供有关如何以适当方式设计功能测试的建议。

结论

我可以继续,但我想我要表达自己的意思。 在开始时,作者关注的是不要反对单类测试和功能测试,而是继续尝试证明后者优于前者。 相反,我认为它们是相辅相成的。

与上述汽车类似,有人会组装原型汽车并将其发送到试驾中,而无需分别测试每个螺母和螺栓吗? 可能不是,因为如果汽车在试驾中撞车:

  • 了解根本原因需要时间和精力
  • 如果根本原因是一个螺母/螺栓出现故障,则可以以更少的时间/精力来更早地发现它

猜猜是什么,它直接转化为功能测试的一些缺点:

  1. 难以调试

当然,功能测试比单类测试具有优势。 但是单类测试也超过了功能测试。

我认为人们很容易丢弃测试金字塔。

如果您想了解有关常规测试和特定于集成测试的更多信息,请不要忘记从Trenches中检查Integration Testing 。

更进一步:
  • 测试复兴
  • 用于集成测试的Spring配置模块化
  • 从Cucumber开始进行端到端测试
  • 变异测试简介

翻译自: https://blog.frankel.ch/unit-test-vs-integration-test/

你可能感兴趣的:(单元测试还是集成测试,为什么要反对?)