{实例：Fibonacci数列}   

    下面的Sample展示TDDer是如何编写一个旨在产生Fibonacci数列的方法。
    （1）首先写一个TC，断言fib(1) = 1;fib(2) = 1;这表示该数列的第一个元素和第二个元素都是1。

public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
}

    （2）上面这段代码不能编译通过，Great！——是的，我是说Great！当然，如果你正在用的是Eclipse那你不需要编译，Eclipse 会告诉你不存在fib方法，单击mark会问你要不要新建一个fib方法，Oh，当然！为了让上面那个TC能通过，我们这样写：

public int fib( int n ) {
return 1;
}

    （3）现在那个TC亮了绿灯，wow！应该庆祝一下了。接下来要增加TC的难度了，测第三个元素。

public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
assertEquals(2, fib(3));
}

    不过这样写还不太好看，不如这样写：

public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
assertEquals(fib(1)+fib(2), fib(3));
}

    （4）新增加的断言导致了红灯，为了扭转这一局势我们这样修改fib方法，其中部分代码是从上面的代码中Ctrl-C/Ctrl-V来的：

public int fib( int n ) {
if ( n == 3 ) return fib(1)+fib(2);
return 1;
}

    （5）天哪，这真是个贱人写的代码！是啊，不是吗？因为TC就是产品的蓝本，产品只要恰好满足TC就ok。所以事情发展到这个地步不是fib方法的错，而是TC的错，于是TC还要进一步要求：

public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
assertEquals(fib(1)+fib(2), fib(3));
assertEquals(fib(2)+fib(3), fib(4));
}

    （6）上有政策下有对策。

public int fib( int n ) {
if ( n == 3 ) return fib(1)+fib(2);
if ( n == 4 ) return fib(2)+fib(3);
return 1;
}

    （7）好了，不玩了。现在已经不是贱不贱的问题了，现在的问题是代码出现了冗余，所以我们要做的是——重构：

public int fib( int n ) {
if ( n == 1 || n == 2 ） return 1;
else return fib( n - 1 ) + fib( n - 2 );
}

    （8）好，现在你已经fib方法已经写完了吗？错了，一个危险的错误，你忘了错误的输入了。我们令0表示Fibonacci中没有这一项。

public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
assertEquals(fib(1)+fib(2), fib(3));
assertEquals(fib(2)+fib(3), fib(4));
assertEquals(0, fib(0));
assertEquals(0, fib(-1));
}
then change the method fib to make the bar grean：

public int fib( int n ) {
if ( n <= 0 ) return 0;
if ( n == 1 || n == 2 ） return 1;
else return fib( n - 1 ) + fib( n - 2 );
}
 

    （9）下班前最后一件事情，把TC也重构一下：

public void testFab() {
int cases[][] = {
{0, 0}, {-1, 0}, //the wrong parameters
{1, 1}, {2, 1}}; //the first 2 elements

for (int i = 0; i < cases.length; i++)
assertEquals( cases[i][1], fib(cases[i][0]) );

//the rest elements
for (int i = 3; i < 20; i++)
assertEquals(fib(i-1)+fib(i-2), fib(i));
}
 

    （10）打完收工。

    {关于本文的写作}

    在本文的写作过程中，作者也用到了TDD的思维，事实上作者先构思要写一篇什么样的文章，然后写出这篇文章应该满足的几个要求，包括功能的要求（要写些什么）和性能的要求（可读性如何）和质量的要求（文字的要求），这些要求起初是一个也达不到的（因为正文还一个字没有），在这种情况下作者的文章无法编译通过，为了达到这些要求，作者不停的写啊写啊，终于在花尽了两个月的心血之后完成了当初既定的所有要求（make the bar green），随后作者整理了一下文章的结构（重构），在满意的提交给了Blog系统之后，作者穿上了一件绿色的汗衫，趴在地上，学了两声青蛙叫。。。。。。。^_^

    {后记：Martin Fowler在中国}

    从本文正式完成到发表的几个小时里，我偶然读到了Martin Fowler先生北京访谈录，其间提到了很多对测试驱动开发的看法，摘抄在此：

    Martin Fowler：当然（值得花一半的时间来写单元测试）！因为单元测试能够使你更快的完成工作。无数次的实践已经证明这一点。你的时间越是紧张，就越要写单元测试，它看上去慢，但实际上能够帮助你更快、更舒服地达到目的。

　  Martin Fowler：什么叫重要？什么叫不重要？这是需要逐渐认识的，不是想当然的。我为绝大多数的模块写单元测试，是有点烦人，但是当你意识到这工作的价值时，你会欣然的。

　  Martin Fowler：对全世界的程序员我都是那么几条建议：……第二，学习测试驱动开发，这种新的方法会改变你对于软件开发的看法。……