什么是“测试驱动开发”

firebody意思将测试代码作为贼详细设计文档，我觉得没这种必要!

一个类内部实现如何设计，直接看类的代码好了．

测试代码仅能反映出来依赖关系，偶而能看出一点协作过程细节，尽量的表达出协作过程作为测试代码的目标吧．

从最简单的测试->增加测试->主观认识发生变化->重构
这样一个不断循环的过程，跟人的认识过程也是一样的，最后得到一个符合要求的设计，这就是所谓的TDD吧．
反正呢TDD就是让我们爱改就改，就算到最后一步，由于认识变化，得推倒重来．．．

针对我前面提的例子，TDD的结果可能有这几种方案:
1） 测试代码

Comp1 mockComp1 = createMock(Comp1);;
Comp2 mockComp2 = createMock(Comp2);;
//反映依赖
Comp comp = new Comp(mockComp1,mockComp2);;
//反映设计的逻辑

//条件分支1
Object result = ...//模拟符合条件分支跳转的数据
expect(mockComp1.logic1(););.andReturn(result);.times(1);;
//条件分支1将执行特定的逻辑logic2();

//这里对被执行私有doSomeInternalLogic方法改变状态的result和result2进//行状态的断定，反映了私有方法doSomeInternalLogic的行为契约。
expect(mockComp1.logic2(););.andReturn(result);.tim2s(1);;
		reportMatcher(new IArgumentMatcher();{

			public boolean matches(Object arg0); {
				Bean b = (Bean); arg0;
				return "tt".equals(b.name);;
			}

			public void appendTo(StringBuffer arg0); {
			}});;
		reportMatcher(new IArgumentMatcher();{

			public boolean matches(Object arg0); {
				Bean b = (Bean); arg0;
				return "b2".equals(b.name);;
			}
mockComp1.logic3(result,result2);;


根据设计，Component组件的代码如下:
COmponent:
private void doSomeInternalLogic1(..);{.....}
private void doSomeInternalLogic2(..);{ .... }
public void doLogic();{
         Object result = comp1.logic1();
        if(result....);{
              Object result2 = comp2.logic2();;
             doSomeInternalLogic1(result,result2);;
            comp2.logic3(result,result2);;

       }
       else{
                    Object result2 = comp2.logic3();;
                     doSomeInternalLogic2(result,result3);;
                     comp2.logic3(result,result2);;
            }
      }

}

这种方案，单独从测试来看，反映了跟外围组件交互的意图，同事很重要的是在调用外围组件交互以前使用了ArgumentMatcher，这个Matcher反映了一个状态由内部方法改变的设计意图。但是在测试代码种，这个方法并没有体现出来，也没有完全体现设计意图。


第二种方案则是robbin说得方案，抽取出一个接口。这样的测试代码就能够清晰的反映设计意图，TDD它总是能够使得设计模块化方向进展，但是并不是唯一的正确的办法。
这里需要一个取舍。
基于“编写可测试性”的代码和基于“反映设计”的编写测试原则，在上面的两个方案得到体现。

在用户故事的范围来说，是这样。说到单元测试，就不一定了，满足同样需求的不同设计，将产生不同的测试。如果先不去想设计，怎么会得到这些不同的测试呢？

如果我把用户故事里的测试作为驱动的源，也就意味着，单元测试是由验收测试驱动的，但不论如何，单元测试都和设计有关。例如：从大的方面来说，采用DomainModel的设计同采用TransactionScript的设计，单元测试就不一样。

一个误解，TDD是从顶向下进行边完善测试边设计的原则进行开发的。
测试完成了，设计也就完成了。
跟平常的考虑设计，写代码，写测试是不同的一个过程。
虽然这两种过程中的脑子里面的对于组件逻辑的构思很有可能完全一致。
但是TDD能够保证你脑子的构思在往好的方面发展，而不至于你脑子里面的“胡思乱想”。

测试和设计到底是什么关系？

一边构思设计一边构思怎么测试这个设计。 但是构思不是凭空想向，而是看着已经写下的测试代码进行的。 脑子的设计有了，不是先写代码，而是先按照构思的设计写期望的测试代码，测试失败，再完善代码。

就是这个关系。

这里有一个很重要的一点：
自顶向下的问题，越早写下的测试代码是越开始的对需求的设计分析。

我自己的定义
设计是什么：设计是问题的解决办法（而不是所说概要设计，详细设计这些东西，这些概念是从被解决的问题所处的位置来说的）．
问题是什么：需求，测试，设计等等都可以作为问题．
测试是什么：验证设计的手段．

测试驱动不是测试，测试驱动是指一种解决问题的办法（因为你要提出问题，测试，观察，改变实现），即是设计．

这样还是Test Driven麽?

我认为这个名词有点绕口， 还不如说“脑子”驱动。 呵呵，不过是先写测试代码而已。

你这里循环引用了,需要解耦。赫赫