在敏捷转型初期，借鉴同业标杆的经验，以Scrum作为组织实践和XP作为技术实践方式进行转型。其中，TDD作为质量保证的核心手段，显得尤为重要。能否严格执行TDD进行研发也是衡量团队转型成熟度的重要标志之一。

1 理解TDD

狭义上TDD的测试指的是单元测试，但是随着敏捷开发方法的发展，TDD又逐渐延伸发展出了ATDD（Acceptance Test Driven Development）和BDD（Behavior Driven Development）等。每种方法关注于不同的问题。

在实践时，针对不同的场景，可以采用不同的模式， T 可以是 UT 或 FT，甚至是ZTP的集成测试。也不需要纠结到底是 TDD、 ATDD 还是 BDD，这只是测试的边界和面相的对象不同而已，关键在于这样做是否能够确保我们的代码实现了设计。

2 实施TDD

在没有外部智力支持情况，团队经历了理论技能普及，团队试点及改进的过程。

2.1 理论启蒙和技能培训

* 在转型初期，我们内部学习《硝烟中Scrum和XP》相关内容，团队觉得TDD很重要。在以前某些阶段，部分团队践行过测试和开发同时进行，缩短交付时间，提早发现设计缺陷。早期的认识仅此而已。

* 产品经理宇总在参加一次外部培训后，在内部进行以单元测试为主的三阶段提交的TDD内训。在后来我们内部推行C++11，SOLID训练营，以及公司内部的gtest培训。（现在来看，当时认识比较浅，意识比较淡薄，并内心并没有完全接受，比较茫然）

* CI中部署单元测试执行和覆盖率统计环节，保证用例可以自动执行。

关键点：

- 必要的理论准备和决策共识是基础。

- 技能培训很关键。

- 全体成员接受理念很重要。

2.2 团队试点

在达到共识后，认为需要将单元测试落地。因此在DOD的定义中，将单元测试作为验收标准可选项。其中，有代表性的就是风行者团队的批价组件和hunter团队的资料接口的单元测试。

批价组件的单元测试是基于功能的TDD。进行单元测试时，代码已经成型，没有遵守三阶段提交的原则。部分用例属于完成开发后补充。初期的资费数据存储在数据库中，加载到基于共享内存的缓存中供测试用例使用。存在用例数据耦合，不方便迁移问题。通过存储包装，将每个用例资费独立处理。每个用例数据为一个单独存储过程文件，迁移时单独数据库文件即可。

基于数据库的单元测试

资料的接口的单元测试是做技术选型时形成的。在进行Redis做资料缓存时，开发测试进行结对。测试人员在开发人员指导下，开发单元测试对于以前的QMDB功能的Happy Path进行测试。在Redis功能开发完成后，可以快速的进行验证。在以后MySQL Cluster以及Qmdb Cluster选项功能研发中，发挥了重要作用，提高了效率。根据数据库类型不同，数据在脚本构造，在运行前执行入库，方便迁移。

这一阶段以自主尝试为主，没有做过多的限制。鼓励尝试，先做出来改进的思路。虽然小有成就，但不足以推广。大部分的TDD，还是以测试先行的ZTP用例来保障。有一段时间陷入迷茫期，单元测试整体进展不大。

关键点：

- 鼓励尝试，鼓励创新；

- 鼓励以强带弱，结对方式；

- 测试数据独立（没有完全做到）；

- 测试先行

2.3 测试框架形成

经过初期尝试后，单元测试进入沉寂期。不知道如何突破才能继续支持，半年个人诉职报告将TDD作为目标，但依然迷茫无法确认复杂业务场景下的单元测试如何破解。期间，参加和标杆公司的TDD的技术交流；公司组织的敏捷教练系统培训。

期间，重温了TDD培训，决定选择Mock DB方式自己来实现测试框架。在开发过程中，严格遵守TDD的三阶段的提交原则（将每个过程截图记录下来作为TDD的大作业）。在Mockdb的基础之上完成了对于资料缓存、余额累积量数据库（Nosql接口）、资料缓存（批量加载）等功能开发，初步形成技术框架。

在内部的分享会上，内部分享自己三阶段提交的TDD研发过程和基于MockDB的技术框架。团队表现出极大的兴趣，在后面迭代中鼓励成员参考示例进行使用，逐步完善。后续在业务层面参考技术框，并形成业务框架，形成三层结构的测试框架来支持整个产品的业务功能测试。后续的迭代中风行者和hunter团队先后到达基本可以依赖新的框架，测试先行或者结对测试方式进行。用例数目和覆盖率都有比较大提升。

另外，结合标杆企业的一些经验，形成TDD测试规范。强调Gevin-When-Then的命名规范；测试用例的独立原则；业务层面用例分割。

基于MockDB的业务框架

关键点:

-  内部倡导整洁测试规范；

- 形成测试框架简化测试用例编写；

- 用例之间数据独立；

- 用例并行执行缩短CI时间

3 展望

TDD在团队确实有了比较大进展，团队成员以及接受测试先行，三阶段提交以及结对等理念，使得以TDD进行功能测试常规化。但是还存在不足和某些缺失，需要不断改进：

- 代码架构不合理，找不到合适的功能测试点。用例业务概念薄弱。

-  Todo List用例分析不足

- 用例表现力方面可能存在不足

- 用例走查较弱，需要关注：关注用例的表达力、是否有重复代码，三段是否清晰。

- 用例遵守FIRST原则：F(Fast)-测试要能快速运行；I(Isolate)-测试用例要独立，不能相互依赖；R(Repeatable)-测试要可以重复运行；S(Self-verifying)-测试会自己检查产出；T(Timely)-测试要及时做，与写代码紧密相连。

- 用例的重构：整合联系紧密的用例；提取合适的类；通过提取的类能够很好表达功能和设计的关系。

小结

测试用例是用来记录设计的，并且在它的约束下，我们可以写出符合设计的代码。因为TDD的测试代码与业务代码有同等重要的可维护方面的要求。如果测试代码质量低下，用例繁多，维护成本也可以巨大，成为一种负担。TDD，且行且珍惜。