很意外我选择了一个自己还算比较感兴趣的论文课题TDD（测试驱动开发），而导师让我挑选的另外一个主题性能测试一不太感兴趣，二大概想了想不同的软件和硬件环境可以搭配出无限种的测试环境，这样的试验和研究实在是让人头疼，而且根据测不准原理，万一答辩时老头跟我较真说：我怎么保证我的测试用例是正确的？我只能回答不能保证；再问我既然测试用例都不正确由它测试出来的程序怎么能是正确的？那时候我只能无奈加无语了。
所以选择了TDD。经过了一段时间才发现，原来测试虽然复杂尚有可操作的余地，而这个挂着测试之名但不是测试的东西让我思前想后没有觅得门路。最开始看来TDD这个名词的提出，以为内容是驱动程序的测试呢，心想这种东西实在无聊，不知道也罢。看过之后才知，TDD正所谓挂羊头卖狗肉者，重点不是测试而是开发，其实是开发方法而非测试方法，这里驱动二字实为动词而非名词，意指：由测试驱动的、带动的开发。不知当初谁人最先翻译成此，实在误人子弟。
TDD是XP方法学中很重要的一部分，倡导测试先行，由测试驱动代码开发。没有代码测试什么？最初我也是这样理解。但实际上TDD是一个非常fantastic的东西，加上现在的编译器十分智能，代码自然而然运用而生。举个简单的例子：
我就写一个狗叫的程序，具体怎么写先不管，先写测试：
Dog xiaobai = new Dog(); //创建一只小狗－小白
assertEquals("wangwang!",xiaobai.bark() ) //判断小白的吠声是不是汪汪
好了，测试写完，run一下，肯定是red bar，同时编译器会告诉你，没有发现Dog这个类，很简单，创建一个，如果你的编译器够智能的话你都不用写 class Dog这句话，点一下错误提示的解决方法就可以了。接着，还有错误，bay这个方法不存在，编译器还会提示你：是否创建一个呢？OK，创建一个：public String bark(){ return "wangwang";} 再run一下，OK，测试通过，是green bar，好了，现在看看是不是想要的代码都出来了？
所以说TDD是个很妙的东西，amazing。然而我的大脑并不妙，还是找不到切入点，TDD这么大的树林里我还都没有发现自己要打的那只鸟，更别提逮到它了。总之埋头苦干，继续努力了。