我们按照 TDD的1个准备步骤+关键5步来看做一个小例子。
需求： 假设我有一个叫Dollar的class, 那它有个方法叫做Times. 我现在的目的是要实现这个Times的方法。
准备步骤1：
基于需求，准备一个Test List，什么是 test list我在前面（TDD( 测试驱动开发) Overview）讲过，比方说这个是抛开代码实现的detail想出来的一些需要测试的东西，换句话说 也是就如果这些测试都通过的话，我就说Times的功能达到了
下面看一下关键5步，我们先测test list中的第一个吧，测试的先后顺序一般是 先挑最简单的测 然后再挑难点的
1. 加入一个新的测试
/// <summary>
///A test for times
///</summary>
[TestMethod()]
public void Test5Times2ReturnCorrectAmount()
{
int amount = 5;
Dollar target = new Dollar(amount);
int actual = target.times(2);
Assert.AreEqual(5*2, actual);
}
2. 运行下新加的测试，看到它失败（因为你还没写功能代码）
下面看一眼 现在Times方法是什么样的--什么都没实现，返回0是为了编译通过，由于没有实现真正的功能代码，这个测试肯定是失败的：
//method to be tested
public int times(int multiplier)
{
return 0;
}
3. 对开发代码做很小的修改，目的就是让新加的测试通过 （注意这里的目的）
目的是用最简单的方法让第一个test case 通过，那代码肯定很简单
//method to be tested
public int times(int multiplier)
{
return 10;
}
4. 运行所有的测试（test case），然后看到所有测试都通过了 （看到测试都变成绿色，一般都会小开心一下）
现在只有一个 运行一下，肯定通过了，现在至少可以小开心一下了
5. 移掉重复的代码，对代码进行重构
这个时候的实现很简单 还没有重复代码。
5步走完，这个test case就测完了，那么就可以从test list 列表中删掉了。
下面开始测第2个test case ： 5 times 10 = 50
依旧是重复以上5步
1. 你加一个test case
/// <summary>
///A test for times
///</summary>
[TestMethod()]
public void Test5Times10ReturnCorrectAmount()
{
int amount = 5; // TODO: Initialize to an appropriate value
Dollar target = new Dollar(amount); // TODO: Initialize to an appropriate value
int actual = target.times(10);
Assert.AreEqual(50, actual);
}
2. 运行新加的test case肯定失败
3. 为了让你的代码通过，你可能会说 那我就写成， 我说可以
//method to be tested
public int times(int multiplier)
{
return 50；
}
4. 这时候你发现第一个test case运行失败了，怎么办？改成下面的样子
//method to be tested
public int times(int multiplier)
{
return this.amount = this.amount * multiplier;
}
5. 看看 上门是否有代码重复，好像有的this.amount，可以变成
//method to be tested
public int times(int multiplier)
{
return this.amount *=multiplier;
}
这样第二个也测完了，可以开始测第三个了。
当你测第三的时候 你可能会准备一个X,Y的array 然后一次调用Times方法，期望它应该返回X*Y，当你加了这个test case 然后运行是 你会发现它已经pass了。
那是为什么呢？答案是 我们在第二步是稍微跨了一大步，不仅达到了第二步的目的，还做了更多的事情（因为经验让我们写出了这个代码）。那这个时候怎么办呢？
我觉得 第三test case的代码得保留（第一：因为测试代码另一个目的就是就是作为需求文档，上面单单从一，二两个test case是看不出一般性的需求的，虽然代码实现的是按一般性的需求实现的，可能以后会给其他程序员带来误会，是客户要求了这个一般性需求还是你程序员个人的想法，程序员自己加需求然后把自己搞死的状况不罕见。 第二：TDD原则上是 有什么样的测试代码 才能有什么样的功能实现代码，不然你就得考虑是否少写了test case）然后第二个 case 可以留着也可以删掉。那为什么不直接就写第三个test case前两个不要呢，这个就不大好了，TDD讲究focus 和small step，引导你思考方式是从简单往复杂。集跬步以至千里，集小流以成江海。目标是“Clean code works”, 不过是先让code work 然后clean。
本来准备讲 怎么实现第四需求的，由于本人准备由这个例子 带出TDD怎么让你Program to interface和在没有用interface情况下怎么测试, 写文章时间可能比较长，准备还是在下篇中讲吧