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

01

—

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

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

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

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

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

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

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

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

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

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

为什么TDD如此重要？

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

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

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

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

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

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

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

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

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

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

TDD的扩展

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

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

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

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

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

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

总结

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

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

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

购书指南

—