2014年我一直从事在敏捷实践咨询项目，这也是我颇有收获的一年，特别是咨询项目的每一点改变，不管是代码质量的提高，还是自组织团队的建设，都能让我们感到欣慰。涉及人的问题都是复杂问题，改变人，改变一个组织是个更复杂问题，这里可能涉及很多的非技术，非能力问题。
在2014年12月我在某企业内部推行TDD(测试驱动开发)培训，一共分4个课时完成一个特定需求的例子，看着大家一步一步的加深对TDD的理解，直到2014-12-31，也是2014的最后一天下午培训完TDD课程，经过一系列的总结过后，某参与人员说道：“单元测试需要写更多的代码，但是从项目的总体来看，一个字‘值’.”。紧接着后来某参与人员发了一份其关于TDD培训感受，名叫《TDD随想录》也将是本文的主题，本文或许更好的说是转载此文，了解一个开发人员对TDD了解的心路历程，以及对TDD的看法。
注：原文发布与hxfirefox的https://github.com/hxfirefox/blog/blob/master/TDD/TDD%E9%9A%8F%E6%83%B3%E5%BD%95.md.
原文如下：
TDD随想录
谨以本文献给TDD的开创者与传播者
本文纯属个人经历，如有雷同纯属巧合
我从不觉得自己是一个好的程序员，甚至可能连合格都谈不上，不过在内心深处我却渴望着在编程这件事上获得成功。
可惜每次审视自己写的暂且称之为代码的东西，都会有挫折感，想重构却又感觉盘根错节，难以下手;想重写却又感觉自己好不容易写出来的，也花了不少心思，就这样丢弃心有不甘。
也曾思考过如何才能写好代码，有段时间觉得只有严格符合编程规范的代码才是好代码进而如同遵守戒律一样地字字斟酌，还有段时间觉得只有用上设计模式才能称之优秀代码进而非模式不用，一切套用模式。不过这些都没有让我走出开发的迷雾，永远是加不完的班，修不完的bug。
究竟是否有一种方法能够让我拨开开发迷雾，至少能够让我能够轻松地修剪代码，降低bug发生率，那么我觉得这种方法在我身上就是成功的。
初次接触到TDD是通过公司内部的“代码大全培训”，犹如十月革命中阿芙勒尔号的一声炮响，为我打开了软件开发的视野。先测试后开发，小步迭代，持续集成，这些新名词突然涌进了我的大脑，既新鲜又晦涩。犹如人的幼年容易犯幼稚病一样，初识这些新名词就以为了解了TDD的一切，结果却发现在实践过程中处处碰壁，举步维艰。对TDD中每个环节真正隐含的开发思想的囫囵吞枣，让这一次的培训只在我脑中留下TDD的一个模糊身影:为软件开发结下一张安全网。
虽然未领悟精髓，但培训后体验和直觉告诉我TDD是一条通往我向往的软件成功的道路，尽管自己摸索前行比较坎坷。很幸运的是团队获得了随队敏捷教练的支持，结对让我系统地了解到了TDD的思想。
测试先行，其实讲的是需求边界，测试不是漫无目的而是精确计算成本的一项活动。测试从何而来，从需求来，需求推演出测试，也规划出产品边界，不能反映需求的测试是一种浪费，因此引申出开发需要讲求适当。开发是一项功利性的活动，永远都在追求盈利，而测试就一条红线，一旦跨过就意味着亏损。
小步迭代，“让子弹飞”中有句话很经典:步子要一步一步迈，一步迈大了，咔，容易扯着蛋。代码堆叠的后遗症是复杂，复杂到没人愿意触碰，且不停地咒骂这代码有多烂，这是步子迈太大的真实写照。TDD讲求的小步迭代是写完一个测试再去写完一个实现，每个实现都是通过测试的，如此累加小胜为大胜，最后所有代码的收尾也不过是让最后一个测试通过而已，就是这样简单。
重构，这是我最喜欢的部分，为啥？因为这里面所有的活动都会要求你去思考，且看上去都像是让你的代码向着大师级代码前进。漂亮的代码并不是堆砌各种技巧，而是在正确的时间，正确的地点做正确的事，重构很容易实现这个目标。重构是一件让人一旦开始就会欲罢不能的事，会让开发者在整个开发阶段都能够不停地去思考、实践再思考，直到无法再添加或删除一个字母。
持续集成，你终究是需要交付产品的，产品就是客户需要的价值，就如同厨师终究会端出客人点的大餐一样，没有哪个厨师是把所有食材罗列着呈现给你的，而是混合在一起，蒸煮炖烧，有些食材需要先处理，这样吃起来才软硬适中，而有些则是最后下锅，这样吃起来才鲜嫩多汁，厨师就是这样一步步将食材集成起来，每一步的处理都是可用都是有价值的，都是为后续进行的铺垫。软件开发也一样，持续集成就要保证每一次的完成都是有价值都可以为后续提供支撑。
写到这里也许会有人问你如何知道TDD是真理，是康庄大道，它一定适合每个人吗？不，我并不知道，我所写的一切只是发生在我身上的一段经历。这段经历告诉我TDD迫使我去更多的思考，去切割我那些冗长且复杂又不切实际的胡思乱想，把它们碾碎成一个个小片段，提炼，过滤，不断累加，最终变成最接近交代价值的东西，而这最终的东西正是我一直在追求的那个成就感。如果想要知道TDD是不是适合自己，最好的办法就是去尝试，去亲身体验一下，无论好坏也许你能获得比我更多的体会。
博主总结
TDD并不是万能的，但是TDD也不是一无是处的，重要的是用方法论的人，引入某同事一句话：
站在教学的角度来讲，我还是很推崇TDD的，TDD是一个很好的思维框架，如果非要教人一个思维框架的话就得教TDD，
不然人会瞎碰，不思考，不总结，不结果导向，靠灵感编程，凭直觉设计，撞大运修bug。最糟糕的是因为没有好的习惯
会接二连三的发生灵异现象。同一道题，习惯不好的人做，总能做出无数种新问题来。而且问题套问题，给他解决要浪费
我半天时间，如果他学会了TDD出的错只在最近一个引入的变化里，就好纠正多了。甚至他自己都能纠正。
博主很是赞同该同事的看法，并且作者认为：
tdd重要的不是测试代码本身，是解决问题的思维，也许可以泛化，哪怕没测试，如果能够做到快速验证，反馈，价值的
稳定叠加，有足够信心，也未尝不可。也许你会说测试可以cover功能，那么如果只有这一点的话，我更喜欢BDD
(behavior-driven development)，因为这具有用户最终的使用价值。如果你说快速定位bug，我们我更倾向于BDD
(bug-driven development，自创的)。这写都是TDD的结果导致的好处所在，而价值反馈思维才是实现TDD背后原理。
TDD驱使我们以结果导向，使得我们简单设计(并不是无设计)，日常重构我们的代码库，注重交付价值流稳定叠加。
不管是《TDD随想录》或者某大牛的《TDD并不是看上去的那么美》，告诉我们世上并没有放之四海皆准的法则，TDD好坏在于你的判断，本文并不会给你一个完美的答案，这需要你自己的发掘。