在程序开发中推行TDD似乎是一件不容易的事情，有的人很热衷，觉得这是拯救项目开发质量的利器，有的人不屑，觉得这不过是给没安全感的人心理的安慰。
很多东西能不能推行就看能不能制定相应的政策进行约束，政策能不能制定就看项目需要不需要。
我们到底想要从TDD中得到什么？unit test能够保证写出来的代码达到质量要求吗？unit test要做到多细？由此带来的额外时间开销是不是能够接受？
项目开发通常陷入debug的泥潭，古来如此，但原因却常常各家不同。
有的可能是开发人员水平不足。
有的可能是开发周期太短，赶工。
有的可能是项目过于复杂。
有的可能是因为项目建立在原有的项目基础上。
TDD会是万众期待的救星吗？
就我自己的体会来说，我觉得TDD并不能拯救项目。
原因有几个：
1.只有要经常改动的地方，才应该加入unit test，但这种常常需要改动的code往往十分不容易加入test。
经常有时，code一改动，unit test跟着改动，unit test的作用只限于当次迭代，这样的test意义何在？
2.大项目里，代码类，函数之间，通常依赖严重，打破依赖是TDD的前提，但这个代价往往很重，甚至让人望而生畏。
而且这般改动也常常带来难以忍受的副作用，如，让代码变得分散，逻辑更多，更难理解。
3.能够测试的代码，通常不容易出问题。
这点是很矛盾的，比如数据库，GUI相关的代码，容易出问题的，往往不是背后的逻辑，而是数据库，GUI。
而这些涉及交互的，基本没法加入unit test.
对于容易加入测试的代码，用写test的时间拿来自己测试，也能保证程序的正确性了。
4.测试用例有时难写全，写代码的人，如果没有意识到自己代码里的错误，他写的测试也倾向于遗漏这些关键点。
很多时候，我们寄希望于unit test能检查出我们的修改带来的问题，这个愿望是十分美好的，但不容易实现。
写程序是一种创造性的活动，很主观的事情，难以像流水线上的工序一样，机械的加以把控。
如果只是纯粹出于对代码质量的要求，code review更能发挥作用。
程序员主观把握自己写的代码的质量，能更加有效。
TDD的推行者，Kent Beck曾在stackoverfloat上回答过一个关于unit test要做到多细的问题：
http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests
他的观点让人有些跌眼镜：老板请我来做开发不是来写测试，要尽可能少Unit test，写出自己有信心的代码。
这里的观点是比较内涵的，如果你对自己的代码有足够的信心，那又何必unit test?
但这不代表就是对unit test的否定，TDD更不是一无是处，做任何事情，适度就好。
对于TDD，不应该把它当成救星，项目质量最根本是在程序员本身，unit test某种程度上就像QA，他们只是反馈问题，并不会改善问题。
unit test的作用应该定位于及早捉住程序员不经意犯的愚蠢错误。
而不是程序质量的把关者。
程序员要对自己写的代码有信心，当然这个信心不是盲目而来，这个信心来源是：严格的代码把控及code review。
前段时间，简悦风云在微博上与网友就TDD有一个讨论，他的观点，我十分的认同：TDD不是救世主，不能为了test而test，反而容易把人的创造力限制了。