谈谈践行 TDD 后的感受

大家好，我是码农小余，今天我们来讨论 TDD。本文纯属个人实践后的感受，若有不确之处，欢迎大佬指导和交流！

细心的童鞋可能看出在小余前几篇文章中都有在实践 TDD。比如 手摸手实现一个编译器（中）、通过一个“时髦”的例子学 Babel 插件 和 重构利器 jscodeshift，它们的共同点是都用了需求整理、拆解分析、写测试用例、编码这个流程——测试驱动开发（Test-Driven Development，缩写 TDD ）。在进入正文之前，可以想想下面这个问题：

TDD 属于编程技术还是规范（意味着 TDD 是一种重要的敏捷需求和敏捷设计技术）？——引自 「首席架构师看敏捷数据」核心实践：测试驱动开发(TDD)简介[1]

流程环

一个 TDD 环如下图所示：

简而言之，TDD 流程包括三个环节：

1. 在写代码之前，先写测试用例；然后执行测试结果，此时因为一行业务代码都没写，结果当然是全部用例都不通过（红色）；
2. 根据测试用例，开始写业务代码，此时测试结果逐渐从红色转为绿色；
3. 等到用例全部通过之后，就是考虑重构事宜的时间节点了。前期为了赶项目进度，可能不会考虑内部质量（即代码质量，不会思考 SOLID 原则和设计模式等）；但在合适的时机（比如空闲时或者下个迭代功能开始之前）务必做重构，这个时间点因为有“绿码”保障，对重构自然也是信心十足。

上述环节要想完美地运作，核心是要做好任务分解和模块拆分。

核心及实践建议

模块分解前提是需求分析。作为手里拿着大斧头的程序员 👨🏻‍💻，看问题一般只会从木头的角度出发（只会从代码实现的角度去思考）。看着交互稿上横坐标有密密麻麻数据的折线图 📈，就想着怎么配置 echarts，怎么去更好地做到响应式显示，而不会考虑使用折线图的价值以及合理性。

简单地过一下需求讲解和交互评审，明白大体的编码逻辑后，不经过需求的剥茧抽丝过程，就匆匆忙忙地开始写测试用例。最后因为模块拆分地不合理，思路不清晰，脑子里更是一团乱麻，测试代码自然就写不下去，最终选择放弃 😔。

上面是小余在实践 TDD 时遇到的一些问题和困惑，但只要稍加强化以下几个点，你的 TDD 之旅定能顺畅许多：

• 摆正心态：既然我们要使用 TDD，就不能怀疑它的价值。有人会因为测试无法捕捉所有的 bug 就不写测试，但却忽略了测试真正的价值是能够捕获大多数的 bug。针对这个问题有一个最佳实践是每当你遇见一个bug，先写一个测试来清楚地复现它，这样能保证你出现过的 bug 不会在出现第二次。
• 任务拆解、模块拆分：做好深度的需求分析，但切勿扎进复杂繁琐的代码实现细节。从需求本身的价值出发，发散梳理需求使用场景，层层递进，彻底掌握、摸清业务的逻辑，模块分层自然就顺理成章且合情合理。
• 测试先行：先写测试能让你的注意力集中在接口设计而非实现。常人思考问题通常都是从“正常路径”出发，即用户使用方式最符合规范的那种场景。但作为合格的程序员👨🏻‍💻，我们应该敏感地想象数据为空时会发生什么？数据边界情况是什么？然后将测试火力集中在这些地方。如此一来，程序的健壮性就得到了保障。有一个误区：测试覆盖率越高越好，每个接口的覆盖率都达到 100% 岂不完美。非也，100% 不是不可以做到，而是这样做的成本远大于收益，这种情况会让你每改动一点需求，都需要花费大量的时间去改动测试用例。（虽说过度设计和过度测试时有发生，但相比测试不足的情况还是少得多）。
• 重构：重构作为 TDD 不可或缺的一环，它直接影响到产品的内部质量（外部质量理解成测试人员从外部对功能进行的测试质量，内部质量指代码质量）。“屎山⛰”不可一日而就，任何产品持续迭代而不做重构，终有惹人嫌，成为同事嘴中“垃圾代码”的一天。有了“绿码”保障，重构能够轻易执行，因为你不再需要手动地测试。什么时候做重构呢？⚠️ 看到“红码”时永远不许进行重构！测试用例中存在失败用例就不应该进行重构。这时应该先让“红码”变成“绿码”，之后再采用“小步慢走”的策略进行重构。《重构，改善既有代码的设计》常伴吾身，因为每进行一个功能开发，都会感叹以前写的代码就是一坨“屎”！在还没有被别人闻到“屎味”（坏味道）之前，及时铲除，你依旧是别人嘴中的“码圣”。

优势

1. 长期运作，能够减少回归 bug 时的改动引发；
2. 代码质量好，TDD 能集中在接口设计而非实现上，还支持频繁地低成本重构，代码的组织、可调试性、可维护性、易读性就水到渠成了；
3. 错误测试代码不容易出现（相比于 行为驱动测试 BDD[2] 先写业务，再写测试代码的流程，后者更可能发生写的测试代码都是错误）；
4. 促进开发、测试及产品经理的交流。要深入了解需求，必须多方交流；如果不采用 TDD ，那这个情况就会发生在你实现业务中间，此时再去改业务逻辑，自然就晚了。只能在业务逻辑上补充各种判断，几百行的函数自然就炼成了。

总结

时时勤拂拭，勿使惹尘埃。尘埃如此，代码亦如此。TDD 的目标是能让你更有组织地完成需求和让代码不染上坏味道的方法论。

最后回到文章开头的问题“TDD 属于编程技术还是规范（意味着 TDD 是一种重要的敏捷需求和敏捷设计技术）？”小余作为一个前端开发人员，我的看法 TDD 是一种编程技术，它能让我更聚焦代码质量，需要花费更多的精力使用 SOLID 和设计模式去打磨写过的代码，这是当前 TDD 带给我的收益。但随着时间的推移和思维的转变，它会潜移默化地成为一种规范。你觉得呢？

参考资料

[1]

「首席架构师看敏捷数据」核心实践：测试驱动开发(TDD)简介: https://cloud.tencent.com/developer/article/1502180?from=article.detail.1053754

[2]

行为驱动测试 BDD: https://en.wikipedia.org/wiki/Behavior-driven_development