2、我们为什么不能用测试反应出需求的变化？如果用户改变了需求，我们先改变我们的测试，然后修改我们的功能代码，这样也没什么不可。

　　3、我想说的是，其实需求的变化频繁是针对整个软件系统的。当落实到具体的某一个类，需求变化不频繁了，甚至不会变化。这是一个粒度的问题。

　　4、不要简简单单的拿出TDD出来讨论，敏捷的很多实践是联系在一起的。我们拿到一个软件需求，会根据用户划定的优先级决定先开发哪些功能。然后我们再将这些功能划分为一个个粒度更小的用户故事，这些用户故事的粒度非常小，在可见的将来他的需求甚至都不会变化，用户故事上还有验收条件，这些都非常具体。当然，这些功能列表，用户故事的划分，验收条件都是有业务分析师和客户一起划分的，不是我们开发人员臆测。所以，在测试驱动开发时，我们用测试反应客户需求绝不是随便瞎扯，因为用户故事粒度很小，所以会描述得很具体，只要你认真的读一下用户故事这部分需求我想你是搞不错的。

　　在Todd的文章中，他频繁的提到我们要尽快的构造出可工作的软件，然后提供给用户，然后等着用户提供反馈。

　　这个我举双手赞成，没问题，我们是要频繁反馈。但是反馈是有代价的，在软件开发中有许多反馈环，比如开发人员到开发人员，开发人员到QA，开发人员到业务人员，开发人员到客户等等。一般来讲，内环的代价低，而自动化的测试是这么一个反馈环，我们编写一个测试，然后编写功能代码，然后测试失败，然后我们写代码让测试通过。我们是在这么一个周而复始的小反馈循环下工作，然后蔓延到更外的反馈环。

　　然后我们来描述一下我们实际的工作情况，怎么来解决这个反馈的问题：

　　前面的划分用户故事不说了。我们在每完成一个用户故事之后会做一次mini showcase，这个时候我们会邀请业务分析师，QA以及其他对这个故事感兴趣的项目组成员参与，这个show很小很短，只要在开发机器上演示一下，然后业务分析人员和QA人员会对一些他们关切点提若干问题，如果这个show通过后QA会将故事卡从正在开发移动到测试阶段。我们有一个迭代周期，为两周。两周后QA和业务分析人员一起会将本迭代周期已经测试好的用户故事收集起来，然后当着客户的面进行演示，然后收集客户的反馈。这个迭代周期也非常重要，如果你们有很合作的客户，而你们的软件属于那种需求变更非常频繁的类型，你大可以缩短这个迭代周期，比如一周。但还是那句话，越外环的反馈需要更大的成本，所以这是一个权衡的问题，我们需要尝试，然后才能确定。

　　敏捷里非常强调反馈，但是过频繁的反馈代价非常大。首先客户不一定会和你一起工作，即使和你一起工作频繁的将不成熟的软件演示给客户影响也不是太好。但是长时间不演示给客户看，很有可能偏离预定的轨道。所以我们要一个反馈周期，要一个个反馈代价递增的反馈环。

　　文章写到这里，都有点乱了，其实我还有很多话要说。

　　后记

　　在测试驱动开发中有一个大忌是在写一个测试，或通过一个测试的时候想得太多。像陈皓所说，WoW是一个非常庞大的软件系统，他有xxx，xxx，xxx，xxx。是的，我都承认，非常庞大，非常庞大。但是再怎么庞大的系统不也是一行行代码编写起来的么？我在编写怪兽移动的代码的时候我为啥要考虑任务系统呢？我们不可能一口吃一个胖子，在做TDD的时候你做好TDD，其他的事情有其他的环节在考虑呢。好吧，那我不测试驱动了，那我到底写不写测试啊？如果你觉得编写测试是有必要的，那么所有TDD会遇到问题都会出现而且会来得更猛烈。所以，测试驱动或许还能减少一些我们的痛苦。

　　当然，如果你的功力已经到了一定的层次，对软件的需求和整体架构也非常了解。有些敏捷实践确实让你觉得太走极端了，那只是说明你已经超越了这些实践，你已经将这些实践当作一种习惯了，你大可抛弃是了。

　　“可测试性”虽然看起来简单，但要达到这个目的跟可扩展性，可靠性等其他软件非功能质量一样，非常难以达到。不过如果你出现的情况跟老赵一样，一拿到需求设计清晰可见，而且还是能构造出松耦合的程序，那么你大可抛弃TDD是了。不过你还要问问自己，你会不会像老赵一样后会补上单元测试。

　　总之，是好是坏自己尝试一下吧，到网上找点相关文章和示例先看看练习练习，然后在自己的项目中试验试验，如果还是不行查找一下自身的原因，如果你后还是发现这玩意儿不适合我自己，那么抛弃便是。