如何对大型MFC UI应用程序进行单元测试？
我们已经开发了许多大型的MFC应用程序，已经使用了多年，我们使用一些标准的自动QA工具来运行基本脚本以检查基本知识，文件打开等。这些由QA小组在每日构建后运行。] >
但是，我们希望引入一些过程，以便各个开发人员可以在将代码提交到日常构建之前，针对应用程序的对话框，菜单和其他可视元素构建和运行测试。
我听说过这样的技术，例如仅出现在调试版本中的对话框上的隐藏测试按钮，是否有用于此目的的标准工具包。
环境是C ++ / C / FORTRAN，MSVC 2005，Intel FORTRAN 9.1，Windows XP / Vista x86和x64。
您如何对大型MFC UI应用程序进行单元测试？我们有一些大型的MFC应用程序已经开发了很多年，我们使用一些标准的自动QA工具来运行基本脚本，以...
取决于应用程序的结构。如果逻辑和GUI代码是分开的（MVC），则测试逻辑很容易。看看Michael Feathers "Humble Dialog Box"（PDF）。
由于您提到了MFC，所以我假设您有一个很难在自动测试工具下获得的应用程序。编写代码时，在构建测试时，您将观察到单元测试框架的最大好处。.但是，尝试以测试驱动的方式向并非设计为可测试的应用程序中添加新功能是一件艰苦的工作。并且令人沮丧。
[我意识到这是一个过时的问题，但对于仍然使用MFC的我们这些人，VS2012中的Microsoft C ++单元测试框架效果很好。
尽管不完美，但我为此找到的最好的是AutoIt http://www.autoitscript.com/autoit3
尽管它不能处理UI端，但我使用Boost Test库对MFC代码进行单元测试。关于入门的代码项目文章：
好吧，我们在工作场所拥有这些庞大的MFC应用程序之一。它是维持或延长它的巨大痛苦……现在它是一个巨大的泥球，但它在草丛中耙开了。
另一种成功的方法是创建一种特定于产品的小型语言，并使用VBScript和一些Control处理间谍魔术来创建脚本测试
实际上，我们一直在使用Rational Team Test，然后使用Robot，但是在最近与Rational的讨论中，我们发现他们没有计划支持更多专注于.NET的Native x64应用程序，因此我们决定切换Automated QA工具。这很棒，但是许可费用不允许我们为所有开发人员启用它。
我们所有的应用程序都支持COM API进行脚本编写，我们通过VB对其进行了回归测试，但这并未对该应用程序进行API本身的测试。
理想情况下，我会对人们如何在开发人员级别将cppunit和类似的单元测试框架集成到应用程序中感兴趣。