我最近的应用程序，我没有代码做真正的TDD。我在编码时保持单元测试，并在编写代码，重构等之后写了我的测试。我做了TDD，当它很容易做…但是我没有那么好的掌握我现在做的是这是第一个充分利用DI，嘲笑框架等的项目，第一个有完整代码覆盖率的项目，而且我从中学到了很多东西。我很痒得分配到我的下一个项目，所以我可以从头开始完成TDD的编码。
我知道这是一个广泛的问题，我已经通过示例和XP Unleashed命令了TDD，但我希望简要概述您如何设计/编写大型应用程序进行TDD。
你写整个应用程序，什么也没有使用stubded代码？ (例如，写入所有功能签名，接口，结构，并写入整个应用程序，但不写任何实际的实现)？我可以把它描绘成中小型的工作，但是这在大型应用中甚至是可能的吗？
如果没有，您将如何编写您的系统中最高级别功能的第一单元测试？例如说 – 在Web服务中，您有一个名为DoSomethingComplicated(param1，…，param6)的函数暴露给了世界。显然，首先为AddNumbers()这样的简单函数编写测试是微不足道的 – 但是当函数位于调用堆栈的顶部，如这样？
你还在前台做设计吗？显然，你仍然想做“架构”设计 – 例如，一个流程图，显示了IE与IIS通信，通过WCF与Windows数据库进行交谈，这个服务与sql数据库进行交互，ERD显示了所有的sql表及其字段，等等…但是课堂设计怎么样？课程之间的相互作用等？您是否设计了这个前端，或者只是继续编写存根代码，重构互动，直到整个事情连接起来，看起来像它会工作？
任何建议非常感谢
不，不是在轻微的意义上 – 这听起来像一个非常浪费的方法。我们必须始终牢记，做TDD的根本原因是快速反馈。一个自动化测试套件可以告诉我们，如果我们比手动测试能够快得多，那么它们就会快得多。如果我们一直等待接线，直到最后一刻，我们不会得到快速的反馈 – 虽然我们可能从我们的单元测试中得到快速的反馈，但我们不知道应用程序是否整体运行。单元测试只是验证应用程序需要执行的一种测试形式。
一个更好的方法是从最重要的功能开始，从那里开始，使用外部的方法。这通常意味着从一些UI开始。
我的方式是创建所需的UI。由于我们通常不能用TDD开发UI，所以我只需使用选择的技术创建视图。没有测试，但我将UI连接到一些API(最好使用声明式数据绑定)，这是测试开始时。
在开始的时候，我会将我的viewmodels /演示模型和相应的控制器，可能是硬编码一些响应，看看UI的工作原理。一旦我有一些不会爆炸的东西，当你运行它，我检查代码(记住，许多小的增量签到)。
我随后垂直工作，沿着这个功能，并确保这个特定的UI可以一路走到数据源(或任何)，忽略所有其他功能。
功能完成后，我可以从下一个功能开始。我描述这个过程的方式是，我一次完成一个垂直切片来填写应用程序，直到所有功能完成。
以这种方式开始一个绿色的应用程序总是需要很长时间的第一个功能，因为这是你必须连接所有东西，所以选择一些简单的东西(如应用程序的初始视图)，以尽可能简单的东西。一旦第一个功能完成，下一个功能变得更容易，因为基础现在已经到位了。
我还在设计前台吗？
不多，不。在开始之前，我通常会考虑整体设计，当我在一个团队中工作时，在开始之前，我们将这个整体架构描绘在白板或幻灯片上。
这或多或少地受到限制
>层数(UI，演示逻辑，域模型，数据访问等)的数量和名称。
>使用的技术(WPF，ASP.NET MVC，sql Server，.NET 3.5或者什么)
>我们如何构建生产代码和测试代码，以及我们使用哪些测试技术
>代码质量要求(配对编程，静态代码分析，编码标准等)
当我们走的时候，我们就知道其余的，但是我们在白板上使用了许多特别的设计会话。
