TDD其实是一项业界争议比较大的实践，尝到甜头的人犹如神教教徒般推行。还在观望的人，心存疑虑，迟迟不敢越雷池。在我的经验中，觉得TDD没什么用的人90%是还不会TDD的人或者以为自己会了的，其余10%是工作在TDD不适合的场景。那么，TDD到底有没有用，要我说，谁用谁知道。
在我的TDD训练营中，为什么要使用TDD这个事情我都不愿意再提。上来先撸两把代码，看看TDD怎么玩的，接着会配合大量的练习，来体会TDD和传统方式的不同之处，它到底能为你带来什么价值，自然就有答案了。
那到底TDD有什么价值呢？我尝试总结归类了几点。
及时澄清需求
Task Driven Development，我们拿到业务需求后会做Tasking，通过Tasking梳理业务需求，将一个大问题进行拆解后，从而能够深入理解业务细节。把一个个业务场景拆分罗列出来后，我们基本上对业务了如指掌，同时你也可以拿着拆分结果，去找业务人员沟通确认，以及澄清一些疑惑点。这个过程恰好体现了敏捷的核心精髓 – 及时反馈。
通过前期的反馈，能够避免因为业务需求理解偏差付出的无用功。
分离关注点
TDD的方式，写测试代码时，我们只关注功能验收，而且只关注特定的一个Task。写功能代码时，只用关注如何完成本次验收，即让当前的测试用例通过。测试通过后，你只用关注代码设计上，思考要不要将代码从刚刚可用的状态改良成简洁可用的状态。这个过程很好分离了我们的关注点，降低思维的负担，帮助专注聚焦，有效地提升开发效率。
构建保护网
TDD的一个必然结果产生是高价值、高覆盖的单元测试，为功能代码提供了一个保护网。这样一来，我们可以充满信心地进行代码重构，去改善我们的代码设计。
另外，相信你在项目上遇到过因为代码集成造成的功能破坏，这种情况多半是代码没有足够测试覆盖，集成时被破坏后没法及时发现。反馈延迟，必然增加维护成本，所以通过构建测试保护网，将大大缓解这种痛点。
减免调试
可能你会发现，采用TDD后，代码量会增加，貌似开发效率就会降低了。试想一下，如果没有单元测试，你就可能要手工测试（如果你还是一位负责人的专业程序员）。那么，手工测试时，在准备数据、启动应用、界面操作等事项上会花费你很多时间，而且大多数工作还需要重复去做，并且获得反馈周期拉长。
有了单元测试，你可以省去很多重复的手工操作，每次运行测试能够快速获得反馈，减免了繁琐的调试工作。
促进新人培养
如果团队来了几个新人，你需要带他们快速进入正常的业务开发，而迫于有限的精力，你不能做到同时跟几个人Pair。此时，教会他们Tasking是非常有帮助。你能够从新人的Tasking结果中能够快速确认他们对业务需求的理解是否正确，提前给出指导反馈，控制好方向。
另外，培养新人以终为始的这种思维习惯也是对他们的职业生涯有益的。
如果你在践行TDD过程中发现了其他有意义的价值，欢迎留言分享哦~
155-2731-8020