最后，类必须集成在一起，以使应用程序可运行，即将必要的代码放在调用必要逻辑的Main方法中。但是，我看不到如何以“测试第一”的方式做最后的整合步骤。
我想如果我使用“自上而下”的方法，我不会有这些问题。问题是：我该怎么做？我应该通过测试Main()方法吗？
如果有人可以给我一些指针，那将是非常感谢。
外部是BDD的术语，其中我们认识到系统通常有多个用户界面。用户可以是其他系统以及人。 BDD方法类似于TDD方法;这可能会帮助你，所以我将简要介绍一下。
在BDD中，我们从一个场景开始 – 通常是使用该系统的用户的简单示例。围绕这些情景的对话有助于我们确定系统应该做什么。我们编写一个用户界面，如果需要，我们可以根据该用户界面自动执行场景。
当我们编写用户界面时，我们保持尽可能的薄。用户界面将使用另一个类 – 一个控制器，视图模型等 – 我们可以为此定义一个API。
在这个阶段，API将是空类或(程序)接口。现在我们可以编写用户界面如何使用此控制器的示例，并显示控制器如何提供价值。
这些例子还显示了控制人责任的范围，以及如何将责任委托给其他类，如存储库，服务等。我们可以使用嘲笑来表达该代表团。然后，我们写这个类，使示例(单元测试)工作。我们只写了足够的例子来使我们的系统级场景通过。
我发现通常会重新制作嘲弄的例子，因为嘲讽的接口首先被猜到，然后在类写入时就会更充分地出现。这将有助于我们定义下一层接口或API，为此我们将描述更多的示例，等等，直到不再需要更多的嘲讽，而第一种情况通过。
当我们描述更多的场景时，我们在类中创建不同的行为，我们可以重构以消除在不同场景和用户界面需要类似行为的重复。
通过以外在的方式，我们可以获得尽可能多的信息，尽可能快地重新编写API。这符合Real Options (never commit early unless you know why的原则)。我们不创建任何我们不使用的东西，而API本身是为了可用性而设计的，而不是易于编写。代码倾向于以更自然的风格使用领域语言编写而不是编程语言，使其更易于阅读。由于代码读取的大约是写入的10倍，这也有助于使其可维护。
