测试驱动开发（Test Driven Development）这一概念大概是06年初左右在学校一个技术活动中听说的。当时还是大二，没有什么实际开发经验，觉着这个概念不错，大公司们应该都是真么执行的。可惜直到研究生毕业工作近五年的现在，在经历过的三家公司中都未曾真正遇见这种开发模式。不说测试驱动了，大多时候连单元测试都未必会去写。在先前思考了Code Review之后，也想试着去理解为什么TDD没能广泛落地？
可测试代码不易实现
最主要的一点原因可能是不易实现可测试的代码。以个人经验来看，代码的可测试性比可维护性更难达到。当一个新手加入这个行业时，其添加的代码很难满足可测试性，随着经验积累，个人的技术水准得到了提高，但当年遗留下来的代码却并不一定有机会重新实现过，因此项目整体可能依然处于不可自动测试的状况。另一种情况则是，经过多年的工作，个人的技术水平并没有能够提高，那么其产出的代码就更不可能具备可测试性了。
单元测试实现“麻烦”
这里的“麻烦”只的是依赖内容准备的麻烦。比如为了测试代码的边界情况就需要准备各种边界数据，用mock或是其它各种方式。类似这些繁琐且不易让人获得成就感的工作总是会让人望而怯步，有时会陷入能省则省的境地。
多变的需求导致测试代码维护成本过高
好的测试代码应当也是易于维护的。不过很多情况下，测试代码本身可能实现的并不是很好，这样再遇到多变的需求，测试代码的改动工作量就变得不能忽视。一旦认为实现测试代码是负担，那么在非强制下，能够主动去实现单元测试的人就会变少。
工具链不完备
比如缺少统一的持续自动集成系统，缺少单元测试运行错误的强制提醒工具等等，导致一些测试代码年久失修。在某些时刻因为项目繁忙或是其它原因，测试代码一旦得不到维护，后面再想补上就困难了。工作量在这里，但谁来背呢？
意识不到位，过于依赖专职的QA测试人员
虽说开发需要对自己的代码负责，但在整体工作流程上，项目的质量也会依赖专职的测试人员。既然后面有人能兜底，那么为什么要过多实现测试代码呢？在这种想法下，想期望测试驱动开发能落地就是妄想了。
将时间用于实现测试代码得不到认可
测试代码的实现与维护都是需要时间的，这部分工作时间在非技术驱动的团队中很可能得不到认可。辛辛苦苦工作下来，领导却觉得是你的能力不足或是在磨洋工，这个事情就更不可能去做了。
总结
以上是自己认为的可能导致TDD没能大范围得到推广的原因。作为团队的个人需要有测试驱动的意识，作为团队的负责人需要去创造一个良好的环境。很多事情都可以去做，比如，
- 不断学习，提升代码质量，使之易于测试
- 将琐碎的工作自动化，降低工作乏味度
- 整理工具链，让成熟的工具帮助我们去完成任务
- 技术布道，让技术成员认可其价值、让非技术人员理解其意义