TDD TDD落地实践总结和展望

admin · December 31, 2020 · 95 hits

在敏捷转型初期,借鉴同业标杆的经验,以 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 的命名规范;测试用例的独立原则;业务层面用例分割。

关键点:

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

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

- 用例之间数据独立;

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


3 展望

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

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

Todo List 用例分析不足

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

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

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

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


小结

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

「软件匠艺社区」旨在传播匠艺精神,通过分享好的「工作方式」,让帮助程序员更加快乐高效地编程!

No Reply at the moment.
You need to Sign in before reply, if you don't have an account, please Sign up first.