在结对编程期间，我们有很多机会获得新的需求，回顾我们的设计与实现，通过对这一特定需求的理解，认识到整个模型是错误的，我们需要从头编写。此时，我们做了 许多人想都没有想过的事情——我们删除了系统中的所有类和单元测试，然后从头再来。通过这种方法获得的经验教训以及对其他需求的理解，可以引导我们开始一 个新的设计，它能够考虑我们需要的功能——但是，我们仍然能够在我们需要的基础上，编写现有的功能。我们虽然没有创建“未来的代码”，但通过额外的接口和 抽象提供了可扩展性……

        我已经反复强调了这样一个循环：“设计、修改、重新设计、修改、重新开始构建、修改”。根据我的经验，最终的结果值得我们这样去做——系统中更少的bug，更加准确地表示业务需求的模型，更好的扩展性和灵活性，从而允许在未来作出修改。
        5. 尽早地修复它。如果你现在不修复它，你可能会在以后做更多的工作，因为会有一些新的内容与这些错误的内容产生交互，从而使得你必须同时修改错误的内容与新的内容。如果你现在就修改错误的内容，就不必在后面重写新的内容了。
        6. 如 果你正在修改一个测试所指的含义（例如，对测试进行重命名，使得它准确表达测试的内容与原因），那么，你可以自动地删除一个旧的测试，创建一个新的——即 使你只是从语义上对它进行删除，你仅仅只是进行重命名以及修改很少的细节。如果测试代表的含义仍然是相同的，你就可以只修改某些实现细节（因为根据根据问 题4，你修改了设计），然后保留这个测试，而只是修改实现去满足新实现的需求。
        7. 参见问题4的回答。

        此外， Derick Bailey还谈到了其他有关TDD的问题，例如对断言的比较，对SetUp方法的分析，对重构工具的认识等。

        对于这7个问题，我的回答如下：

        1、 预先设计的度并没有一个准确的值。首先对于一个系统而言，我们应该从领域与架构的角度分析技术关键点，并对这些关键点进行预先设计，是非常有必要的。此 外，对于系统的infrastructure的内容，我们也需要预先设计，除非这些内容是已经存在的。其实，如果采用领域驱动设计的方式开展对领域逻辑的 分析，那么何时开始做测试，应该没有太大的歧义，它自有一套规则需要我们遵循。TDD并不是完全排除设计的作用，利用测试来驱动开发，其实同时也代表我们 可以利用测试来驱动设计。因此，我的意见是如果将系统各个组成部分看作是package或者component，那么理想地TDD起点应该是在 package或component被划分好之后，我们就可以利用单元测试来驱动我们对领域模型的思考与编码实现了。
        2、这个问题没有什么好说。如果是问题中的例子，我想没有什么好争论的，正如Derick Bailey所说，我们确实不会对Main方法进行单元测试。我赞成Derick的意见。
        3、 显然，如果能够利用工具来模拟桩对象，何乐而不为？如果测试代码依赖的接口和实体类，本身就是我们在实现系统时就需要的，那么实现它们算不上是无用功，此 时，我赞成先去定义或者实现它们。不过在定义和实现它们的同时，需要考虑到这些定义不一定完整与准确，我们还要考虑随时会对其进行修改，修改后，还要必须 检验你的测试代码。
        4、既然发现有问题，为什么要暂时放过，以观后效呢？我的思想一贯都是要将错误扼杀在摇篮中。否则，因为一时偷懒放过的这个问题，往往会在后面给我们带来无穷无尽的烦恼。如果你不能确认这些错误，拿出来讨论是一个比较好的办法。
        5、与问题4相似。
        6、 具体看修改的范围。如果测试需要修改的不会影响依赖它的测试用例，即不会修改它的外部接口，那么只需要修改部分实现代码就可以了。没有必要去专门编写一个 新的测试用例。如果涉及到对外部接口的需要，可以考虑重构。例如Derick提到的重命名的问题。如果重构不能解决，那就可以编写一个新的测试。
        7、很显然，与问题4相同。