在项目实践中使用TDD，我经常会被问到以下问题，这让我很无助：
- TDD可以帮助你设计吗？
- TDD可以帮助你明确需求吗？
- TDD可以帮助提高质量吗？
- TDD是正确的吗?
- TDD有经过科学的收集数据，通过数据对比来验证吗？
这些问题都很常见，让我无助的不是这些问题答不上来 - 其实都有很明确的答案，让我无助的是也许大家在项目实践中遭受太多苦难，当大家发现一个有用的工具或者方法论时，无不寄希望于她能帮助我们解决所有的问题。其实人家Fred Brooks早在1987年就看穿了这一点，并发表了一篇关于咱们这个行业-软件工程的经典论文《没有银弹》。核心思想就是 - 没有任何一项技术或方法可以让软件工程的生产力在十年内提高十倍。Fred Brooks已经把这个期限放的很宽了，十年。我认为这个“十年”绝对是打破幻想的精准一击，话外语就是，不管我给你多少年，你也还是一样找不到这样一枚银弹，是不是有点绝望。再看看以上问题的“正确”答案，你因该会更绝望：
- TDD可以帮助你设计吗？
不能，如果你本身就不会好的设计，那也没有一种方法能让你一下就会。
- TDD可以帮助你明确需求吗？
不能，需求如果本身就不明确，也没办法通过TDD让她明确。
- TDD可以帮助提高质量吗？
不能，如果你写的代码质量就是不行，不管用什么办法，你写出来的肯定还是自己的代码。
- TDD是正确的吗?
不知道，还没有谁通过科学的办法验证这个是否正确。
- TDD有经过科学的收集数据，通过数据对比来验证吗？
没有，因为这个过程中的变量因子太多太多，自身能力的成长就是不可衡量因子其中之一。
什么？看起来TDD一无是处？从上面的答案来看，我还真没法反驳你，但我仍然选择坚持TDD。
我现在的一项主要工作就是培训新入职的毕业生，希望公司的敏捷文化在最开始的时候就可以尽可能全面的呈现在大家面前，让大家知道什么是我们鼓励的，什么是我们向往的。
在我们的培训中，TDD被我们设计成OOBootCamp中第一个重要的环节，在这之前会有敏捷简史的介绍，用来帮助大家理解大的背景。也有关于单元测试的介绍，帮助大家了解单元测试，从而能够区分哪些是测试带来的好处，哪些是TDD带来的。
之所以坚持，当然不是因为需要坚持而去坚持，而是如何真正的去了解她，知道如何跟她Pair(结对儿)。
TDD是一个方法论，和GTD - 时间管理、 PKM - 个人知识管理一样，只是一个方法论。
TDD能够提高编码的效率，能够尽量避免纠结，节约你的时间。当你一个人不知道先做什么后做什么的时候是，当两个人结对儿的时候尤是。
通常与TDD同时出现的词还有 Unit Test(单元测试，我们这里的TDD指的是uTDD)， Pair(结对儿编程)。
TDD可以保证Pair质量，保证双方都能动手实践，思路统一，增强参与感。
设定了以上期望，我相信TDD能更好的为你所用。毕竟能够帮助我们解决实际问题，才是王道。
