以测试为驱动的程序并非只是关于测试的
我喜欢问的技术问题是要在一定程度上能放映应试者的真知灼见的，他们不但要能显示自己的技术深度和广度而且更重要的是要能充分的理解一个软件的开发过程。所以我非常高兴一个同事能提供给我一个很好的面视的问题，就是“以测试为驱动的开发的要点是什么？”
以测试为驱动的开发（TDD）是从敏捷开发和极限编程（XP）的实践中产生的。极限编程约定了一套最好的实践例子来共同证实一些核心价值的东西如反馈和简单化。反馈是以测试的形式发生，通过传达简短的反复和通过简单的有效的彼此交谈。简单化是处理软件最重要因素和明确软件目前的需要
Kent Beck ， 最初的XP编程的拥护者，把软件开发的本质称之为以测试为驱动的开发，而且这个观点同样得到范例开发者的认可，TDD的观点是发现软件切实需要的功能，而不是程序员所认为的软件应该具有的功能。当然一般情况下也许你会觉得这样做违反直觉，但是这样做不仅有意义而且将很快成为一个自然而且优雅的软件开发方法：在我们写一些客户代码之前我们要假想好要开发的代码已经存在而且已经完全写好。
这是一个得到普遍认可做法：通过写一个我们代码的客户端摸板，以测试的形式，我们能定义出我们需要的最适合的API。另外，我们要声明我们需要的行为。很明显的这不能运行甚至无法编译，而且这违反直觉的部分代码将成为其他API的一部分甚至是现在不存在的API的一部分！下一个阶段就是去写最小数目的代码去编译测试代码，这就够了，一个简洁的编译，然后你能运行测试用例（这个用例在这个阶段还无法运行）现在有一些IDE 如ITelliJIDEA 或者开放源代码组织Eclipse 都为你产生缺省的类和接口方法，现在，你编写应用程序代码去满足测试，最终的那一点点疑惑是去重审那些代码让它越来越简单，然后成为你软件开发的节奏：写测试用例，写代码，重审在你写代码之前要先写测试用例，要关注于什么才是完全需要的，在很大程度上，这意味着你在开发中做的是系统所需要的东西而不是多余的东西。而且你能很容易在将来添加更多的功能，因为它们都是测试驱动的我们保留我们写过的测试用例而且把它们全部拿来运行，这样可以确保系统拥有我们预先所需要的功能（而且能很快的更正了我们不认可的功能）
不管用何种方法，我们已经创建了非常有用的测试用例，这些都是在实施TDD过程而得到的一个间接利益，所以当你在面视的时候，某些人问你关于以测试为驱动的开发的问题的时候，记住它不是关于测试的。而是关于如何发现你最需要做的事和如何简洁明了的去做，好了！现在如果再有人问你去如何用橘子去填满房间这个问题的时候。你应该知道该怎么回答。
