单元测试MFC UI应用程序？

如何对大型MFC UI应用程序进行单元测试？

我们有一些大型MFC应用程序已经开发多年,我们使用一些标准的自动化QA工具来运行基本脚本来检查基础,文件打开等.这些由QA小组在每日构建后发布.

但我们想介绍一些过程,以便各个开发人员可以在将代码提交到每日构建之前,根据对话框,菜单和应用程序的其他可视元素构建和运行测试.

我听说过只有在调试版本中出现的对话框上的隐藏测试按钮等技术,是否有任何标准工具包.

环境是C++/C/FORTRAN,MSVC 2005,Intel FORTRAN 9.1,Windows XP/Vista x86和x64.

既然你提到了MFC,我假设你有一个很难在自动化测试工具下使用的应用程序.在编写代码时构建测试时,您会发现单元测试框架的最大好处.但是尝试以测试驱动的方式将新功能添加到不是可测试的应用程序中......可能很难并且非常令人沮丧.

现在我要提出的建议绝对是艰苦的工作 ......但是有了一些纪律和毅力,你很快就能看到好处.

首先,您需要一些管理支持来修复新修补程序需要更长的时间.确保每个人都明白为什么.

接下来购买WELC书的副本.如果你有时间,或者如果你很难按,请阅读封面以覆盖,扫描索引以查找应用程序所展示的症状.本书包含许多好的建议,正是您在尝试使现有代码可测试时所需要的.

然后,对于每个新的修复/更改,花一些时间并了解您将要处理的区域.在您选择的xUnit变体中编写一些测试(免费提供)以执行当前行为.

确保所有测试都通过.编写一个测试所需行为或错误的新测试.

编写代码以进行最后一次测试.

在测试区域内无情地重构以改进设计.

从此处重复您必须对系统进行的每个新更改.这条规则没有例外.

现在是承诺的土地:很快就会有越来越多的经过良好测试的密码岛开始出现.越来越多的代码属于自动化测试套件,变更将逐渐变得更容易.这是因为缓慢而可靠的底层设计变得更加可测试.

简单的出路是我之前的回答.这是艰难但正确的出路.

这取决于应用程序的结构.如果逻辑和GUI代码是分开的(MVC),那么测试逻辑很容易.看看Michael Feathers "Humble Dialog Box"(PDF).

编辑:如果你考虑一下:如果应用程序没有这样的结构,你应该非常仔细地重构.没有其他技术可以测试逻辑.模拟点击的脚本只是在表面上划伤.

这实际上非常简单:

当用户单击按钮并且您希望确保列表框包含单击后的正确内容时,假设您的控件/窗口/无论何种更改列表框的内容.

重构,以便有一个单独的列表,其中列出了要显示的列表框的项目.这些项目存储在列表中,不会从您的数据来源中提取.使列表框列表的代码只知道新列表.

然后创建一个包含逻辑代码的新控制器对象.处理按钮单击的方法仅调用mycontroller-> ButtonWasClicked().它不知道列表框或其他任何东西.

MyController :: ButtonWasClicked()确实需要为预期的逻辑完成,准备项目列表并告诉控件更新.为此,您需要通过为控件创建接口(纯虚拟类)来解耦控制器和控件.控制器只知道该类型的对象,而不是控件.

而已.控制器包含逻辑代码,仅通过接口知道控制.现在,您可以通过模拟控件为MyController :: ButtonWasClicked()编写常规单元测试.如果您不知道我在说什么,请阅读Michaels的文章.两次.之后再说.
(自我注意:必须学会不要那么多)