2014年我一直从事在敏捷实践咨询项目，这也是我很有收获的一年，特别是咨询项目的每一点改变，无论是代码质量的提升，仍是自组织团队的建设，都能让咱们感到欣慰。涉及人的问题都是复杂问题，改变人，改变一个组织是个更复杂问题，这里可能涉及不少的非技术，非能力问题。git
在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.github
原文以下：编程
TDD随想录
谨以本文献给TDD的开创者与传播者设计模式
本文纯属我的经历，若有雷同纯属巧合安全
我从不以为本身是一个好的程序员，甚至可能连合格都谈不上，不过在心里深处我却渴望着在编程这件事上得到成功。框架
惋惜每次审视本身写的暂且称之为代码的东西，都会有挫折感，想重构却又感受盘根错节，难如下手;想重写却又感受本身好不容易写出来的，也花了很多心思，就这样丢弃心有不甘。单元测试
也曾思考过如何才能写好代码，有段时间以为只有严格符合编程规范的代码才是好代码进而如同遵照戒律同样地字字斟酌，还有段时间以为只有用上设计模式才能称之优秀代码进而非模式不用，一切套用模式。不过这些都没有让我走出开发的迷雾，永远是加不完的班，修不完的bug。测试
到底是否有一种方法可以让我拨开开发迷雾，至少可以让我可以轻松地修剪代码，下降bug发生率，那么我以为这种方法在我身上就是成功的。firefox
初次接触到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好坏在于你的判断，方法论的主体在于使用的人，本文并不会给你一个完美的答案，这须要你本身的发掘。