由于我是 TDD 新手，我目前正在开发一个小型 C# 控制台应用程序以便练习(因为熟能生巧，对吧？)。我首先对如何组织应用程序(按类)进行了简单的草图绘制，然后开始逐个开发我可以识别的所有域类(当然，首先是测试)。
最后，必须将这些类集成在一起以使应用程序可运行，即将必要的代码放在调用必要逻辑的 Main 方法中。但是，我看不到如何以“测试优先”的方式完成最后一个集成步骤。
我想如果我使用“自上而下”的方法，我就不会遇到这些问题。问题是:我该怎么做？我应该从测试 Main() 方法开始吗？
如果有人能给我一些指示，将不胜感激。
最佳答案
“自上而下”是 already used in computing to describe an analysis technique .我建议改用“由外而内”一词。
由外而内是 BDD 中的一个术语，我们认识到一个系统通常有多个用户界面。用户可以是其他系统，也可以是人。 BDD 方法类似于 TDD 方法。它可能会对您有所帮助，因此我将简要介绍一下。
在 BDD 中，我们从一个场景开始——通常是用户使用系统的简单示例。围绕场景的对话帮助我们弄清楚系统应该做什么。我们编写了一个用户界面，如果需要，我们可以针对该用户界面自动执行场景。
当我们编写用户界面时，我们会尽可能地精简它。用户界面将使用另一个类—— Controller 、 View 模型等——我们可以为其定义一个 API。
在这个阶段，API 要么是一个空类，要么是一个(程序)接口(interface)。现在我们可以编写用户界面如何使用此 Controller 的示例，并展示 Controller 如何交付值(value)。
这些示例还显示了 Controller 职责的范围，以及它如何将其职责委托(delegate)给其他类，如存储库、服务等。我们可以使用模拟来表达这种委托(delegate)。然后我们编写该类以使示例(单元测试)工作。我们只写了足够的示例来使我们的系统级场景通过。
我发现修改模拟示例很常见，因为模拟的接口(interface)一开始只是猜测，然后随着类的编写而更加全面地出现。这将帮助我们定义下一层接口(interface)或 API，我们为此描述更多示例，依此类推，直到不再需要模拟并且第一个场景通过。
随着我们描述更多场景，我们在类中创建不同的行为，并且我们可以重构以消除不同场景和用户界面需要相似行为的重复。
通过以由外而内的方式执行此操作，我们可以获得尽可能多的关于 API 应该是什么的信息，并尽可能快地修改这些 API。这符合 Real Options (never commit early unless you know why 的原则。 )。我们不会创建任何我们不使用的东西，并且 API 本身是为可用性而设计的——而不是为了易于编写。代码倾向于使用领域语言而不是编程语言以更自然的风格编写，使其更具可读性。由于代码的阅读量大约是编写量的 10 倍，这也有助于使其可维护。
出于这个原因，我会使用由外而内的方法，而不是自下而上的智能猜测。我的经验是，它会产生更简单、更强大的解耦、更易读和更可维护的代码。
关于tdd - 使用 TDD : "top down" vs. "bottom up"，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4570303/