TDD 容易被忽略的五大前提

发布于:2018 年 12 月 2 日 12:08

TDD容易被忽略的五大前提

TDD 不仅仅是一项技术,它还是一种完整的编程风格,一种相关行为和思想的综合系统。TDD 的五个前提为我们提供了一个操作闭环,就像每个 TDD 实践者呼吸的空气一样。

软件教练 GeePaw Hill 在 eXperience Agile 2018 大会上谈到了 TDD 的五个容易被忽略的前提。InfoQ 通过问答、摘要和文章的形式报道了这次会议。

Hill 表示,测试驱动开发(TDD)的五个前提构成了几乎所有 TDD 实践的基础,它们将我们与这种测试驱动方法联系在一起。

Hill 提出的五个前提是:

  • 金钱前提——我们是为了金钱。

  • 判断前提——我们将依赖做出局部决策的个人。

  • 相关性前提——内部质量生产力。

  • 链接前提——我们主要测试非常小的部分。

  • 指导前提——测试和可测试性是一等设计参与者。

Hill 说,当你在实施 TDD 时,这些前提是不可见的,但它们仍然非常重要。在进行 TDD 时,你必须牢记这些。

金钱前提是关于资金的来源。TDD 不是关于测试、改进质量或工艺。Hill 说,TDD 的目标是更快地交付更多的价值,就是为了金钱。

判断前提意味着我们完全依赖个人的判断。Hill 认为,他自己每次都在做同样的事情,但对于其他人来说却不是这样。TDD 不是编码算法,当你在进行 TDD 时,必须做出决策。

相关性前提是指内部质量和生产力是相关的。Hill 说,它们之间有着直接的关系,一起起起伏伏,因为它们都依赖于技能和领域知识等东西。Hill 认为,保持代码的良好状态并不只是个可选项。

链接前提告诉我们,链的测试方法是测试链中的每个链接。程序被分成较小的部分,你必须对这些部件进行测试。Hill 说,测试整个链的成本很高,很难编写测试用例并维护好它们,但是测试链接的成本却是最低的,它提供了最高的覆盖率。

指导前提是说测试和可测试性是设计的一等参与者。Hill 说,如果你没有可测试的设计,其实就是没有设计。你一直在质疑如何进行测试,以及到目前为止测试是如何进行的,从第一行代码到最后一行代码。他说,你必须改变你的设计,让测试尽可能变简单。

在进行 TDD 时,这些前提将在整个过程中发挥作用。Hill 说,它们是隐形的,就像你呼吸的空气一样。

在演讲结束后,InfoQ 采访了 GeePaw Hill。

InfoQ:了解 TDD 前提为什么会如此重要?

GeePaw Hill:如果我们没有意识到这些前提,就很有可能会搬起石头砸自己的脚。对于其中的每一个前提,我都能举出例子,但还是让我们来看看相关性前提吧。

TDD 实践者对代码的内部质量非常着迷,因为他们知道代码且与他们的生产力直接相关。不知道的人很容易将影响内部质量的工作视为一种“清洁”行为。无论人们认为洗碗有多重要,但事实是你可以长时间使用脏盘子却不会受到任何伤害。你可以把清洁工作延后,因为现在你需要的是食物,而不是干净的盘子。你现在需要更多的食物,所以你“这一次”可以跳过洗碗这件事。

但是如果不洗碗就意味着你现在的食物也会减少呢?内部质量并不是清洁工作,因为它是影响生产力的一个主要因素,而不只是一个锦上添花的东西。不良因素所造成的负面生产力效应是非常迅速的,比如糟糕的命名、引入变量和初始化之间的长时间延迟等。理解相关性前提的人永远不会将内部代码质量仅仅视为一个可选项。

InfoQ:我们如何提高 TDD 技能?

Hill:TDD 通常被视为一项简单的技术,但实际上它确实是一种整体的编程风格,而不只是一种新的附加机制,它是相关行为和思想的一种综合系统。空手道技术熟练的人被称为 karetekas,而在柔道中他们被称为 judoka。从古老的风格到现代的综合论,有点像从 kareteka 到 judoka。它涉及很多不同的肌肉群、不同的动作、不同的想法。

话说回来,为了获得丰富的技能,我们必须做同样的事:

  1. 找一个安静的地方,让你敞开心扉。
  2. 阅读和研究。
  3. 练习。

老师或导师可以帮助你完成这三件事,但他们不能替你去做。与所有复杂的学习一样,TDD 没有捷径。

查看英文原文:

https://www.infoq.com/news/2018/11/premises-tdd

阅读数:1160 发布于:2018 年 12 月 2 日 12:08

更多 文化 & 方法、敏捷、方法论 相关课程,可下载【 极客时间 】App 免费领取 >

评论 (1 条评论)

发布
暂无评论
  • Steve Freeman 谈到在大多数 TDD 应用中发生的错误,以及在 SOLID 的基础上创建应用

    在去年举办的敏捷新加坡大会的演讲中,Steve Freeman为听众分析了TDD为什么会被人错误地理解、并且在各种实际应用中会经常产生误用的原因。他同时还说明了为什么SOLID架构原则依然非常重要的原因,甚至很可能比过去的任何时刻都更加重要。

    2015 年 3 月 25 日

  • 互联网产品的测试策略应该如何设计?

    传统软件通常采用金字塔模型的测试策略,而现今的互联网产品往往采用菱形模型,遵循“重量级API测试,轻量级GUI测试,轻量级单元测试”的原则。

    2018 年 7 月 23 日

  • “TDD 已死”之论战调查

    Ruby on Rails的作者DHH最近发出“TDD已死”的言论,这在技术社区引起了轩澜大波,一些技术人员开始纷纷发表各自的看法表示支持或者反对。

    2014 年 6 月 10 日

  • 可测试性如何帮助团队提升效率

    在Agile Practitioners 2016大会上,Huib Schoots谈了可测试性。他指出,低可测试性(任何导致软件难以测试的东西)会导致团队效率低下,并探讨了如何提高可测试性。

    2016 年 2 月 16 日

  • 结课测试 | 建设数据中台的这些知识,你都掌握了吗?

    来测一测,这些与数据中台的相关知识,你都掌握到什么程度了?

    2020 年 5 月 8 日

  • 特别放送 | 从软件工程的角度解读任正非的新年公开信

    软件工程从来不说自己是银弹,就像现代医学,也不会号称自己包治百病,它只会不断改进,对症下药。

    2019 年 2 月 18 日

  • 为什么传统的自动化测试工具会扼杀敏捷?

    最近,关于下一代功能测试工具发展方向的讨论热闹地开了锅。不过,还是众多敏捷组织仍然在努力让传统的“录制-回放”测试工具跟上敏捷的脚步。被称为“测试狂人”的Elisabeth Hendrickson告诉他们为什么不要再白费功夫了。

    2008 年 5 月 7 日

  • 虚拟座谈会:TDD 有多美?

    最近酷壳的一篇有关TDD的文章引起了广泛关注,对于TDD一些人有自己不同的见解,为此InfoQ中文站特地邀请了InfoQ内外的敏捷专家特别是有丰富TDD实践经验的人,就TDD为InfoQ的读者分享他们自己的经验和体会。

    2011 年 2 月 23 日

  • 代码评审:寄望与哀伤

    关于代码评审,有时我们过于寄望,却又不免哀伤。

    2018 年 11 月 14 日

  • 为了可测性而设计

    对于一个复杂的软件系统来说,没有什么比稳定地发生变更来得更重要,而高质量的自动化测试是达成这种目标最重要的工具之一。好的测试不是可遇不可求的,也不是靠蛮力能够获得的:它们是通过设计得来的,因为应用程序赋予了它们这种可能性。当你在开发软件时,时常问自己“我将如何测试软件的准确性”,并且愿意为了达成这个目标对软件进行良好的设计。作为回报,你将得到一个具有良好结构的系统,你也会因此倍感自信。

    2017 年 1 月 15 日