c# - 学习TDD，总是陷入循环依赖

Question

我开始使用 TDD 来提高我的质量和我的代码设计，但我经常遇到问题。我将尝试通过一个简单的例子来解释它: 我尝试使用被动 View 设计来实现一个简单的应用程序。这意味着我试图让 View 尽可能地愚蠢。让我们考虑一个应用程序，其中 GUI 有一个按钮和一个标签。如果用户按下该按钮，则会创建一个文件，其中包含一个随机行。然后标签会显示创建成功与否。 代码可能如下所示:

• IView 接口(interface):单个 setter 字符串属性:Result
• GUIEventListener 类:从 GUI 按钮调用的 OnUserButtonClick 方法
• FileSaver 类:从 GUIEventListener 调用的 SaveFile 方法
• GUIController 类:从 FileSaver 类的 SaveFile 方法调用的 UpdateLabel 方法，其参数取决于 SaveFile 方法的成功与否。

实例化看起来像这样:

• View 的构造函数:View(GUIEventListener eventListener)
• GUIEventListener 的构造函数:GUIEventListener(FileSaver fileSaver)
• FileSaver 的构造函数:FileSaver(GUIController Controller )
• GUIController 的构造函数:GUIController(View view)

如您所见，设计中存在循环依赖。 我通常尽量避免使用事件，我不喜欢用它们进行测试，而且我认为这种类型的设计更容易 self 解释，因为它清楚地说明了类之间的关系。 我听说过 IoC 设计风格，但我不是很熟悉。

关于这个问题，我在 TDD 中的“症结所在”是什么？我总是遇到这个问题，我想学习一种适当的模式或原则以避免将来出现这种情况。

Answer 1

• GUIController class: UpdateLabel method which gets called from the FileSaver class's SaveFile

...

• FileSaver's ctor: FileSaver(GUIController controller)

这是您设计中的缺陷。 FileSaver 应该不知道谁在调用它(读作:不应该持有对其下面层的引用)，它应该只做它的工作，即保存文件并通知世界操作是如何进行的 - 通常通过返回值。

这与 TDD 并没有真正的关系，除了 TDD 可能会迫使您根据 FileSaver 所期望的最基本行为来思考，并意识到更新标签不是它的责任(参见 Single Responsibility Principle )。

至于系统的其他部分，正如 Roy 所说，除了 Controller 之外，它们通常很难在 TDD 中进行测试。