如果你刚接触TDD不久，可能一些常见的问题正在困扰着你：
- 我该容忍多大限度的预先设计？
- 在写测试的时候，可能必须构建出接口和一些类来让代码编译通过——这一步该跨多大？
Chad Meyers写下了一些他在开始接触TDD实践时碰到的疑惑和问题，它们应该都是比较常见的：
- 我该容忍多大限度的预先设计？你怎么知道应该何时停止（也就是说，“当人们开始讨论算法，就是该测试的时机了”）？
- 对于象“我心里清楚我们需要这个”这类东西——我们该如何处理（例如，在控制台main()方法中加上一个try/catch{Console.WriteLine(ex);}？）
- 编写测试时，为了让代码编译通过，你不得不写下一两个接口，一个实体类，在类中还有一些NotImplementedExceptions等等。这一步该走多远？
- 如果在测试一个用户故事期间，你发现先前的预先设计有问题，你是会马上停下来跟你的搭档讨论，做该做的事，然后继续；还是折返回去，在当前的故事中采用完整的测试优先模式？
- 在处理一个新的用户故事时，你发现针对前一个故事所编写的测试已经不再体现需求。你是否会立刻重构那个测试，还是把它标记为“忽略”，等你完成当前的故事再回过头去处理那个被忽略的测试？还是有其它做法？
- 如果新的用户故事要求对某个已有的测试做出轻微调整，你是会调整它，还是会写一个新测试，把旧的扔掉（也就是，“不许更改现有的测试代码！”，或者“只有出现小的编译问题时才准动它，否则就别碰！”）？
- 如果你构建了模型并且通过了测试，但是你发现这个设计很幼稚，而且即将要做的用户故事肯定会对其进行重大修改，并生成一个新的完全不同的模型。你是应该退 一步，考虑进行大型重构吗？还是应该继续修修补补，调整现有的模型，尽管这个模型最终会被目前看来显然超出该用户故事范围的工作所改进？
Derick Bailey分享了他对Chad这些问题的看法。他很谨慎的说，这些都是基于他自己的亲身体会，所以你的实践经验可能会跟他的不同。下面是他的回答：
- 知道自己应该构建什么就行。
这个问题实际上应该根据你的实际项目来回答。我最近做了一个企业集成项目，里面用到了我们的核心维护系统，然后添加了一些离线操作功能。在这个项目中，我 没有做太多的预先设计。我知道系统需要能够在离线模式下操作，我还知道即使是没人登录计算机或者运行这个软件时，它也需要能够执行一些操作，我知道它需要 跟主维护系统进行双向通信，用来执行与维护相关的的一定数量的任务。我从一些设想/预先设计开始动手——构建了一个Windows Service来运行核心进程，构建了一个客户端-服务器架构来托管UI，在一个消息系统上为通信提供支持。除了这些算是预先设计以外，在构建软件的过程 中都是其他各项任务的功能需求来驱动项目设计的进展。
最近，我与一个为实验室开发某系统的团队一起工作时，有了截然相反的体验。我们有源于客户的需求，客户所要求的流程，以及对客户手中数据进行转换的需要； 我们需要一个大规模的预先设计，用以判断我们的解决方案可以满足数据转换和功能需求。系统的核心设计是预先完成的，但是具体实现还是在开发过程中慢慢成 型。
如果你还是TDD新手，这些问题可能会听起来很熟悉。这些问题的最佳答案应该到先行者那里去寻找，他们可能存在于某个本地用户社区，或者众多在线的开发者邮件列表中的一个。换个角度来说，如果你已经有了充分的TDD经验，请与大家分享
一下你对这些问题的答复。
