单元测试MFC UI应用程序?

既然您提到了MFC,我假设您的应用程序很难在自动化测试工具下运行。在编写代码时构建测试时,您将看到单元测试框架的最佳好处。。但是,试图以测试驱动的方式将新特性添加到不可测试的应用程序中。。可以是艰苦的工作和令人沮丧的。

现在我要提出的是 艰苦的工作 .. 但只要有一些纪律和毅力,你很快就会看到好处。

• 首先,您需要一些管理支持,以便新的修复需要更长的时间。确保每个人都明白原因。
• 下一步,买一份 WELC book . 如果你有时间或者手头很紧,请逐个阅读,扫描索引以查找你的应用程序所显示的症状。这本书包含了很多好的建议,这正是您在尝试使现有代码可测试时所需要的。
• 确保所有测试都通过。编写一个新的测试,测试所需的行为或bug。
• 编写代码使最后一次测试通过。
• 在测试区域内无情地重构以改进设计。
• 现在 :很快,不断增长的经过良好测试的代码孤岛将开始浮出水面。越来越多的代码将归入自动化测试套件,更改将变得越来越容易。这是因为基础设计慢慢地、肯定地变得更易于测试。

最简单的办法是我以前的回答。这是一条艰难但正确的出路。

这取决于应用程序的结构。如果逻辑和GUI代码是分离的(MVC),那么测试逻辑就很容易了。看看迈克尔·费瑟 "Humble Dialog Box" (PDF)。

编辑:如果你仔细想想:如果应用程序不是这样构造的,你应该非常小心地重构。没有其他测试逻辑的技术。模拟点击的脚本只是表面现象。

其实很简单:

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

1. 重构,以便有一个单独的列表,其中包含列表框要显示的项目。这些项目存储在列表中,不会从数据来源提取。使列表框列出内容的代码只知道新列表。
2. 然后创建一个新的控制器对象,该对象将包含逻辑代码。处理按钮单击的方法仅调用mycontroller->按钮单击()。它不知道列表框或其他任何东西。
3. MyController::ButtonWasClicked()执行预期逻辑所需的操作,准备项目列表并通知控件进行更新。为此,您需要通过为控件创建接口(纯虚拟类)来解耦控制器和控件。控制器只知道该类型的对象,而不知道控件。

就这样。控制器包含逻辑代码,仅通过接口了解控制。现在,您可以通过模拟控件为MyController::ButtonWasClicked()编写常规单元测试。如果你不知道我在说什么,请阅读迈克尔的文章。两次在那之后。
(自我提醒:必须学会不要说那么多)

我意识到这是一个过时的问题,但是对于那些仍然与MFC一起工作的人来说,VS2012中的微软C++单元测试框架工作得很好。

一般程序:

1. 将MFC项目编译为静态库
4. 在测试项目的配置属性中,为头文件添加Include目录。
5. 在链接器中,输入选项添加MFC.lib;nafxcwd.lib;libcmtd.lib;
7. 在“常规”下,添加MFC导出的lib文件的位置。

这个 https://stackoverflow.com/questions/1146338/error-lnk2005-new-and-delete-already-defined-in-libcmtd-libnew-obj

虽然不是完美的,但我发现最好的是AutoIt http://www.autoitscript.com/autoit3

“AutoIt v3是一种类似于基本免费软件的脚本语言,旨在实现Windows GUI和通用脚本的自动化。它结合使用模拟击键、鼠标移动和窗口/控件操作,以其他语言(如VBScript和SendKeys)无法实现或不可靠的方式自动化任务.AutoIt也非常小,是独立的,可以在所有开箱即用的Windows版本上运行,无需烦人的“运行时”

当您有权访问被驱动的应用程序的源代码时,这种方法很有效,因为您可以使用要驱动的控件的资源ID号。这样,您就不必担心在特定像素上模拟鼠标点击。不幸的是,在遗留应用程序中,您可能会发现资源ID不是唯一的,这可能会导致问题。然而将ID更改为唯一并重新生成是非常简单的。

另一个问题是,您将遇到计时问题。对于这些问题,我没有一个行之有效的解决方案。我使用的是反复试验,但这显然是不可扩展的。问题在于,AutoIT脚本必须等待测试应用程序响应命令,然后脚本才会发出下一个命令或检查正确的响应。有时,要找到一个方便的事件来等待和观看并不容易。

我的感觉是,在开发一个新的应用程序时,我会坚持使用一致的方式来表示“就绪”。这将有助于人类用户以及测试脚本!对于遗留应用程序来说,这可能是一个挑战,但也许您可以在有问题的地方引入它,并随着维护的继续慢慢将其扩展到整个应用程序。

Designing Robust Objects with Boost

我们在工作场所有一个巨大的MFC应用程序。这是一个巨大的痛苦,以维持或延长。。。它现在是一个大泥球,但它会在沼地里耙

• 我们使用 Rational Robot 用于进行烟雾测试等。

• 另一种已经取得一些成功的方法是创建一种小型的产品特定语言和 脚本测试 使用VBScript和一些控制手柄的间谍魔法。将常用操作转换为命令。。e、 g.OpenDatabase将是一个命令,它将依次注入所需的脚本块以单击主菜单>文件>“打开……”。然后创建excel工作表,这些工作表是一系列这样的命令。这些命令也可以接受参数。有点像健康测试。。但更多的工作。一旦您确定了大多数常用命令并准备好了脚本。它是用来编写新测试的拾取和组装脚本(由commandid标记)。测试运行程序解析这些Excel工作表,将所有小脚本块组合成一个测试脚本并运行它。

  1. OpenDatabase“C:\tests\MyDB”
  3. 添加型号“M0001”,“MyModel”,2.5100
  4. 按OK
  5. 保存数据库

嗯

实际上,我们一直在使用RationalTeamTest,然后是Robot,但在最近与Rational的讨论中,我们发现他们没有计划支持更多关注.NET的原生x64应用程序,所以我们决定切换自动化QA工具。这很好,但许可成本不允许我们为所有开发人员启用它。

我们所有的应用程序都支持一个用于脚本编写的COM API,我们通过VB对其进行回归测试,但这不会测试应用程序本身的API。

理想情况下,我会对人们如何在开发人员级别将cppunit和类似的单元测试框架集成到应用程序中感兴趣。