单元测试MFC UI应用程序？

StackOverflow https://stackoverflow.com/questions/107591

题

你怎么单元测试大MFC UI应用程序？

我们有几个大MFC应用程序，已在发展多年来，我们使用的一些标准的自动化QA工具运行的基本脚本检查的基础，打开文件等。这些都是由QA组后的每日建立。

但我们想向大家介绍的程序，这样，个人开发者可以建立和运行测试的对话，菜单和其他可视元素的应用程序之前提交码的每日建立。

我有听说过这样的技术，如隐藏的测试按钮上的对话，只有出现在调试版本，是否有任何标准工具包。

环境C++/C/FORTRAN MSVC2005年，英特尔FORTRAN9.1，Windows XP/Vista x86&64.

有帮助吗？

解决方案

这取决于应用程序的结构。如果逻辑和GUI代码是分开的（MVC），那么测试逻辑很容易。请参阅Michael Feathers “Humble Dialog Box”（PDF）。

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

实际上非常简单：

当用户点击按钮并且你想确保列表框包含点击后的正确内容时，假设你的控件/窗口/改变了列表框的内容。

  1. 重构，以便有一个单独的列表，其中包含要显示的列表框的项目。这些项目存储在列表中，不会从您的数据来源中提取。使列表框列表的代码只知道新列表。
  2. 然后创建一个包含逻辑代码的新控制器对象。处理按钮单击的方法仅调用mycontroller-＆gt; ButtonWasClicked（）。它不知道列表框或其他任何东西。
  3. MyController :: ButtonWasClicked（）确实需要为预期的逻辑做好准备，准备项目列表并告诉控件更新。为此，您需要通过为控件创建接口（纯虚拟类）来解耦控制器和控件。控制器只知道该类型的对象，而不是控件。

    4. 多数民众赞成。控制器包含逻辑代码，仅通过接口知道控制。现在，您可以通过模拟控件为MyController :: ButtonWasClicked（）编写常规单元测试。如果您不知道我在说什么，请阅读Michaels的文章。两次。之后再说。
    （注意自己：必须学会不要那么多）

其他提示

既然你提到MFC，我假定你有一个应用程序，将难以获得下一个自动化测试的利用。你观察的最佳利益的单元的测试框架的时候你建立测试作为你写的代码..但是，试图添加新的功能，在一个试验驱动的方式应用程序的设计不是测试..可以努力工作，以及令人沮丧。

现在我要提出肯定是 艰苦的工作..但一些学科和毅力，你会看到的利益很快就足够了。

  • 第一你需要一些管理支持新的修正采取多一点的时间。确保每个人都能理解为什么。
  • 接下来买一个副本 教学书.读它涵盖以涵盖，如果你有时间，或者如果你很难，扫描的索引，以找到症状你的程序是参展。这本书包含了很多好的建议和正是你需要的时试图获取现代码进行测试.alt text
  • 然后为每个新修/改变，花一些时间和理解该地区的你会的工作。编写一些测试中，来完成的变你的选择(自由)行使目前的行为。
  • 确保所有的测试通过。写一个新的测试练习需要的行为或错误。
  • 编写代码，以使这个最后的测试通过。
  • "重构"毫不留情地在该地区在测试，以改进设计。
  • 重复为每一个新的改变，你必须做到系统从这里。没有此规则的例外。
  • 现在 应许之地:很快不断增长的群岛的经过良好测试的代码将开始面。更多的代码属于自动测试和变化将逐渐变得容易做到的。这是因为缓慢和当的基础设计变为更多的检测.

简单的出路是我以前的答案。这是困难而正确的方式。

我意识到这是一个过时的问题，但对于我们这些仍在使用MFC的人来说，VS2012中的Microsoft C ++单元测试框架运行良好。

一般程序：

  1. 将MFC项目编译为静态库
  2. 向您的解决方案添加新的本机单元测试项目。
  3. 在测试项目中，将您的MFC项目添加为参考。
  4. 在测试项目的配置属性中，添加头文件的包含目录。
  5. 在链接器中，输入选项添加您的MFC.lib; nafxcwd.lib; libcmtd.lib;
  6. 在“忽略特定默认库”下添加nafxcwd.lib; libcmtd.lib;
  7. 在“常规”下，添加MFC导出的lib文件的位置。

    8. https：// stackoverflow。 com / questions / 1146338 / error-lnk2005-new-and-delete-already-in-libcmtd-libnew-obj 很好地描述了为什么需要nafxcwd.lib和libcmtd.lib。

    在遗留项目中检查的另一个重要事项。在“常规配置属性”中，确保两个项目都使用相同的“字符集”。如果您的MFC使用多字节字符集，您也需要MS测试。

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

“AutoIt v3是一种免费的类似BASIC的脚本语言，用于自动化Windows GUI和通用脚本。它使用模拟击键，鼠标移动和窗口/控制操作的组合，以便以其他语言（例如VBScript和SendKeys）不可能或不可靠的方式自动执行任务。 AutoIt也非常小巧，独立，可以在所有版本的Windows上运行，没有烦人的“运行时”。所需＆QUOT;！

当您可以访问正在驱动的应用程序的源代码时，这很有效，因为您可以使用要驱动的控件的资源ID号。通过这种方式，您无需担心特定像素的模拟鼠标点击。遗憾的是，在遗留应用程序中，您可能会发现资源ID不是唯一的，这可能会导致问题。然而。将ID更改为唯一并重建非常简单。

另一个问题是你会遇到计时问题。我没有这些尝试和真正的解决方案。我曾经使用过试验和错误，但这显然是不可扩展的。问题是AutoIT脚本必须等待测试应用程序在脚本发出下一个命令或检查正确响应之前响应命令。有时候找一个方便的事件等待和观察并不容易。

我的感觉是，在开发新应用程序时，我会坚持采用一致的方式发出“准备就绪”的信号。这对人类用户和测试脚本都有帮助！对于遗留应用程序而言，这可能是一个挑战，但也许您可以将其引入问题点并在维护继续时将其慢慢地传播到整个应用程序。

虽然它无法处理UI端，但我使用Boost Test库对MFC代码进行单元测试。有关入门的代码项目文章：

使用Boost设计健壮的物体

嗯，我们有一个这些堆积如山的MFC应用程序在工作场所。它是一个巨大的痛苦，以维持或延长...它是一个巨大的泥球，但现在它耙在moolah。不管怎么说

  • 我们使用 合理的机器人 这样做的烟雾测试等。

  • 另一种办法，已取得了一些成功是建立一个小型的产品-特定语言和 脚本测试 使用VBScript和一些控制手柄上的间谍魔法。打开共同的行动纳入命令..例如OpenDatabase将是一个命令，该命令将注入所需的脚本块击的主菜单>文件>"打开...".然后，您可以创建excel表格这是一系列这样的命令。这些命令可以采取的参数。东西就像一个适合测试。。但更多的工作。一旦你有了大部分的共同命令，确定和脚本准备。这是选择和组装脚本(标记的通过CommandIDs)编写新的试验。一个测试者分析这些Excel表格，将所有小脚本块试脚本和运行。

    1. OpenDatabase"C: ests\MyDB"
    2. OpenDialog"添加模型"
    3. AddModel"M0001","MyModel",2.5,100
    4. PressOK
    5. SaveDatabase

禾田

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

我们所有的应用程序都支持用于编写脚本的COM API，我们通过VB对其进行回归测试，但是测试API并不是应用程序。

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top