用于MFC应用程序的任何可测试的架构或设计模式

测试GUI列表仍然是一项可怕的任务。有一些工具可以帮助您跟踪和重播交互式输入。我使用了一些API(从Perl窃取的代码)将按键事件注入到另一个应用程序中(在firefox中打开一个新url，而不总是打开一个新选项卡)。但这对于测试来说还不够好。

高级工具花费数千美元，并附带外部脚本语言和可用性报告。http://en.wikipedia.org/wiki/List_of_GUI_testing_tools

GUI测试有两个不同的领域。一个是填写带有用户选项的对话框，另一个是模型/视图测试。

第一个问题可以通过一些编码规则轻松解决。例如，对话框不修改任何东西，而是接受和返回带有所有选项的类。在这种情况下，您可以简单地用自己的代码替换对话框代码。这是简单的部分。在我的代码对话框中修改ini文件设置，然后用一些提示通知模型发生了什么变化。

测试视图和模型要困难得多。如果它是一个关于绘图，您可以尝试使用WM_PRINT消息来捕获视图，然后运行测试并将其输出与先前捕获的数据进行比较。如果位图相同，则测试通过。我从未真正在现实世界中看到这种技术的应用，除了在一个工具包中，它使用它在多个平台上测试像素精确绘图。

下一步是测试一个基于交互代码的模型。正如前面提到的，键事件更容易模拟——无论如何，大多数都直接转换为分离的命令处理代码，因此只需测试命令而不是键事件处理程序。鼠标选择和操作，例如画布上的对象选择，就困难得多。要么使用这个测试工具之一，它承诺捕获和重放鼠标动作，要么祈祷。

有许多不同的方法取决于你自己的代码库，如果你从MFC抽象足够好，使用模拟GUI对象，而不是真正的MFC窗口。如果你已经嵌入了一个脚本语言，它可以帮助你测试东西等等。很抱歉没有简单的模式。这得根据具体情况来决定。

我自己的经验是，我根本不喜欢单元测试GUI和单元测试。通常不值得花时间。我正在使用Eiffel和契约式设计(这意味着有很多断言语句)，并与客户进行了广泛的beta测试，让客户找到剩余的bug。大多数bug都是不可测试的可用性bug。

你是说MVC?它存在于文档/视图架构中，但控制器部分有些缺失。你仍然可以把GUI从数据中分离出来，但把模型从视图中分离出来的真正好处是，你可以在其他地方使用它，但至少对于doc/view来说，这并不容易。

Edit: Add on:至于测试功能，MFC应用程序附带了命令行处理。您可以以此为基础，从命令提示符向应用程序发送测试命令。

我认为您可能不需要任何特殊的设计模式来将逻辑与UI分开。MVP可以提供帮助，但可能不是实际必要的。如果您可以将逻辑放入单独的dll或静态库中，并使它们能够从其他应用程序访问，那么这种分离对于测试来说就足够了。这将是一个很好的开始，使您的逻辑实际上是可测试的。

但是在此之前，我会为您的开发环境找到一个好的测试框架。我在使用Google测试框架或Boost测试时取得了一些成功。

至于设计模式，它们对于使您的程序可维护性和最大化代码重用非常好，但我不确定使用它们使您的程序可测试是否是一个好的实践。可测试性是程序的一个很好的属性，但它可能不是你设计的目标。