没有 TDD/ATDD,你的持续交付可能是持续找死

栏目: 编程工具 · 发布时间: 4年前

内容简介:01—

一场关于DevOps能力评估的讨论,引发了对TDD的争论。

01

一场争论

前几天,我们在讨论如何提升整个部门的DevOps能力。

公司有一套统一的DevOps的能力评估流程,有具体的要求供各系统团队进行自我评估。自我评估觉得达标的,可以申请评审委员会进行评估,评估通过,就可以采用简化的上线流程,从而支持系统每日多次上线的需要。

当然,我们的焦点并不是要求所有系统都要通过评审,因为即使我们通过评审,业务也未必需要我们每日多次上线。

我们希望能通过自我评估,看看自己离目标有哪些具体的差距,从而确定改进方向,制定具体的改进方案,提高持续交付的能力。

由于我们有大量的遗留系统和供应商系统,业务部门的组织架构也很复杂,很难确定谁是PO,要实现全流程的DevOps,并不容易。但也有一些新搭建的外围系统,采纳了最新的架构、技术和框架,看似更容易实现DevOps。

当问起一个从去年开始开发的新系统的情况时,团队代表自信满满地说他们已经有CI/CD流水线,而且有足够的自动化测试代码覆盖率,所以已经具有持续交付能力了。诚然,那是一个基于Spring Boot/Spring Cloud微服务架构的新系统,有成熟的配套 工具 和框架支持持续交付。

但当我问他们有没有实施TDD(测试驱动开发)时,他们回避了这个问题,认为TDD只是开发流程,他们的自动化测试代码覆盖率还是比较高的。

我说代码覆盖率并不能说明什么问题。 如果没有TDD,如何确保测试用例的有效性?

在场的同事都觉得讨论TDD有点过于具体了。

我的结论是, 没有TDD,你的持续交付可能是持续找死

02

为什么TDD如此重要?

提高持续交付能力,经常会从搭建CI/CD流水线开始。但是搭建流水线,就是搞搞Jenkins、Nexus和Ansible吗?

首先我们要搞清楚什么叫CI(持续集成)。我在《 敏捷与DevOps里没有最佳实践,只有正确姿势 》,如果没有对CI的正确运用,它很容易沦为一个纯粹的打包工具。

CI的灵魂是自动化测试的持续执行。 持续交付,需要自动化测试的保驾护航 ,否则就是 找死的裸奔

而这些自动化测试从何而来?来自TDD—— 在开发前就想好测试用例 ,从而快速反馈代码是否满足需求。

关于测试,重点还是 测试用例的编写能力 。“ 自动化测试 ”这个定义有点误导性,其实叫“ 半自动化测试 ”更准确,因为它 只是自动化了测试执行过程 ,并没有自动化测试用例的生成。但 测试的难点和重点就在于测试用例 ,这一点还得靠人。手工执行也好,自动化执行也罢,如果测试用例的覆盖率和有效性不足,结果都是一样的。

这也是自动化测试落地的难点,难的不在于自动化测试工具的应用,而是自动化测试用例的编写——每一个需求的测试用例都不一样,和需求分析、开发的难度不相伯仲,这些在前敏捷时代也是难啃的骨头。

TDD要求我们在编写代码前,认真思考如何测试。有了这些测试代码,不但可以为我们的代码带来即时的质量反馈,这也是敏捷倡导的 快速反馈 的一部分,也可以为重构、变更保驾护航,大大提升整个系统的 可变更性

TDD不是一个先开发还是先测试的顺序问题。设想一个很简单的问题,如果是先开发再补自动化测试,你开发的代码都已经交付了,还 哪有动力去做测试自动化

TDD也能确保代码质量,为了让代码满足可测试性,势必要满足 低耦合单一职责 的要求——一个方法只实现单一功能,这样,一个输入就只有最有限的输出可能,从而容易测试。相反,那种会有多种输出可能的长方法,很难测试所有可能性。

TDD很难,因为它不符合一般 程序员 急于下手写实现的冲动,但它也是提升程序员代码质量和交付信心的一剂良方,理应成为每一个有担当的程序员的习惯。

03

TDD的扩展

对TDD的另一个抵触声音是,TDD针对的是单元测试,而费那么大劲(各种Mock)摆弄单元测试的自动化,又不能很好地覆盖业务,有什么意义?

所以,我们需要把TDD的理念进一步延伸,变成 验收测试驱动开发(ATDD) 或者是 实例化需求 —— 在开发前与用户约定具体的验收测试用例 是什么,从而对验收、完成,达成共识,形成交付闭环。然后测试团队在开发期间把验收测试自动化了,以便在开发完成时进行及时验收,并成为CI的一部分。

这是唯一确保测试用例覆盖率和有效性的方法。

这很难,因为它改变了人们的习惯,但是它很重要。

试想想如果没有在开发前和用户约定好验收测试用例,用户会怎么验收?大几率是拍脑袋验收。然后上线出了问题就甩锅。

事前约定验收条件,就是希望一次把需求做对,减少返工,避免扯皮。

04

总结

自动化测试是实现持续交付的基础,也是CI/CD流水线的必要条件,但也是实施的难点。

而TDD或ATDD,是确保测试用例覆盖率和有效性的唯一方法,也是持续交付的基石。

TDD或ATDD成为了你或团队的习惯了吗?如果没有,为什么?欢迎 留言 讨论。

关于作者

刘华(Kenneth)

  • 就职于世界500强银行,负责基金服务业务软件开发与交付

  • 敏捷、精益、DevOps专家

  • 精通极限编程、 Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

  • 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会等论坛发表主题演讲

  • 著有《猎豹行动:硝烟中的敏捷转型之旅》一书

没有 TDD/ATDD,你的持续交付可能是持续找死

小说体敏捷/DevOps转型教科书

和实战经验分享

购书指南

纸质书、电子书在 京东当当亚马逊 等渠道已全面上架,搜索关键字“ 猎豹 敏捷 ”即可找到。点击 阅读原文 可直接购书。

有声书已登录 喜马拉雅 ,适合路上听书的你。

没有 TDD/ATDD,你的持续交付可能是持续找死 没有 TDD/ATDD,你的持续交付可能是持续找死

长按关注V社北京

测试 技术 面试 DevOps

关注V社北京,关注测试,添加巨蜥小程序获取全量精品技术文章

没有 TDD/ATDD,你的持续交付可能是持续找死

关注我

每天进步一点点

觉得好看,点个“ 在看 ”或转发给朋友们,欢迎你 留言


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

You Can Program in C++

You Can Program in C++

Francis Glassborow / John Wiley & Sons / 2006-7 / 406.80元

An interactive and fun way to learn C++, one of the most popular high-level programming languages for graphic applications This unique, hands-on approach to learning C++ makes t......一起来看看 《You Can Program in C++》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

随机密码生成器
随机密码生成器

多种字符组合密码

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具