干货｜TDD落地：从僵化、优化到固化的过程

点击上方“中兴开发者社区”，关注我们

每天读一篇一线开发者原创好文

作者简介

作者张均，中研院认证敏捷技术教练。代码匠艺精神的推广者和实践者。致力于TDD、重构、DDD、TLA+和DSL等实践的落地。这篇文章主要回忆了在实际项目中如何运用TDD进行实践的一个历程，和总结了对技能提升的僵化优化固化过程，欢迎大家拍砖交流。

管理进步讲究“僵化、优化、固化”三步曲，能力提升包含“学习、思考、分享”三层次。

僵化式学习，优化式创新，固化式提升，进一步学习，个人能力扩展的一种框架。

僵化式学习：了解框架流程

人的思维和行为容易固化，学敏捷，学TDD等，容易产生抵触情绪。“如何学”就成为一个重要问题。僵化就是学习初期阶段的“削足适履”。是一种学习方式。先僵化，说起来容易做起来难，削足适履肯定是个痛苦的过程。变则痛，但世界上唯一不变的事情就是变化。学习TDD时，一定要重复的“红灯-绿灯-重构”，抵制诱惑，快速实现。不经过多次僵化练习，是很难感受到TDD内涵、放弃抵触情绪的。

个人学习：

熟悉《整洁代码》、《重构》、《敏捷软件开发：原则模式实践》，并有一定见解。

坚持参与外部代码静修活动和TDD讨论群，找到志同道合的小伙伴，拉其一起入群讨论，参加外部代码静修，多向业界TDD实践者进行学习。

社群学习：

1、开展团队内每周一晚上1题练习活动，采用TDD方式完成Code Chef练习题；

2、代码COP活动；

3、新员工培养：整洁代码、编码规范、重构和TDD的系列代码道场活动。

通过僵化式学习，对TDD有一定的理解，单元测试和场景拆分的技能有一定提升。

优化式创新：融入工作

优化就是改进，优化就是创新。优化的目的是使知识变得更高效更适用。僵化而不优化一定会僵死。“TDD很好，但是不实用”，听得最多的这句话，是错误的。TDD是流程或框架，在使用时需要借助方法和工具，比如：实践结对编程，以点带面，形成氛围；善用TDD的驱动设计，容易忽略的重构加强，改善设计；对存量代码补充UT时，以业务场景驱动而不是代码驱动，黑盒测试。

TDD与结对开发：

为了解决软件项目开发团队人员技能参差不齐和重交付轻质量思维，团队内部可设置代码专家守护团队代码，每日代码走查活动中，针对逻辑修改和新增，关注UT覆盖率和代码圈复杂度目标。对人员能力的提升，就需要代码专家和开发人员对走查提出的问题进行结对修复。代码专家引导开发进行UT用例补充和技巧传授。

收益：通过该实践，开发人员实际写单元测试的意识获得提升。

TDD与业务梳理和故障定位：

对代码流程中一个超过1000行的复杂方法，涉及多个业务分支，如何梳理代码进行故障清理？我们选择了TDD，从外部流程上看走该部分代码的所有可能场景，对每个场景，我们需要的结果是怎样的，挨个场景补充单元测试，尽可能完成场景覆盖后，再去发现和修改对应故障。

收益：除解决问题，还发现很多潜在的问题；同时由于有完整UT场景的保证，通过驯服烂代码活动（工作之外大家对这块烂代码集体重构活动），额外收获做到了业务知识的传递。

TDD与复杂场景需求：

对接口的稳定性和异常处理要求很高的项目，针对AC开发需求时，TDD开发就为场景细化提供了保障，对需求代码要求严格的UT分支覆盖完全，需求开发过程中不断的TDD三部曲无疑解决了找不到集成环境自测的问题。

收益：除单元测试覆盖和代码健壮性提升，减少了QA的手工验证工作量。

固化式提升：能力提升

将僵化阶段优化阶段的成果心得，进行固化。固化的目的是为了总结分享，以便别人或者自己进一步学习。固化的方式有多种，比如总结文档，最佳实践，模板化等。 这里的模板化举个例子，比如存量代码单元测试的依赖隔离使用mock，可将使用到所有mock技术的一个实例模板化，那么对新人就不必再去摸索，如果完成这个模板，就可认为mock的技能达到初级阶段。固化也是简化。

上述实践，不断总结回顾，反馈和调整。最终人员形成如下意识：

走查代码的习惯发生了变化：对代码评审活动，习惯关注测试代码的业务场景描述。达到知识分享和消除每日代码走查的疲劳的目的。

解决故障的思路发生了变化：不在因为为了解决故障而改代码，而是更多得梳理代码，发现故障周边的场景；解决故障不引入新故障不再是底线，而是解决一个故障规避一堆故障。

对特性和场景拆分站得更高：我们的AC变得更细，我们的场景变更更全，这都依赖于澄清会和计划会上小伙伴们都能提出更多的场景来。

结语

TDD的争议性，项目的导向性，个人能力限制，导致普遍软件从业者认为对TDD落地很疑惑。  

关于“TDD如何落地？”，关键在于我们面临的具体问题，我们想要用TDD框架来怎么解决。也许有人会问你实践的TDD不是TDD，但那又怎样？解决了我们的问题或者提升了我们的技能，就够了。