与单元测试相比,GUI 测试要耗时和困难的多,即使是在测试驱动的开发团队中,因此也常被忽视。让我们来看一看两个为 SWT 和 Swing 应用创建 GUI 测试的解决方案,它们均宣称能够使 GUI 测试工作更加简单。
为什么 GUI 测试难以编写?比起简单的实例化一个类,GUI 通常需要更多的创建工作,同时因为 GUI 交互是异步的而且涉及到鼠标操作,所以难以模拟 用户行为。GUI 测试的一个方法是提供一个交互录制器,监控测试人员,创建一个以后能够重用的脚本。这种方法存在若干问题:根据录制格式的不同,脚本在 UI 改变之后可能难以修改;很自然地,测试优先的开发模式不可行。
另外一种选择是编程创建 GUI 测试。这依赖于框架是否适合编写测试。找到一个能够识别 UI 元素和相关设施,并能等待异步操作结束的简单并有效办法至关重要。 SWTBot 和 Marathon 都用于为 Java 应用编写 GUI 测试。SWTBot 使用 Java,所以存在使用 JRuby 的可能性。Marathon 则更进一步,直接使用 JRuby(或者 Jython)编写测试脚本。
SWTBot
SWTBot 是一个用于 SWT、基于 Eclipse 应用的测试工具,提供了简化访问 SWT 和 Eclipse 组件的 API。测试脚本可以通过 Ant 任务运行,因此你可以把测试集成到持续集成构建中。SWTBot 基于 Apache 2 许可协议。
InfoQ 采访了 SWTBot 的开发人员——Ketan Padegaonkar。Ketan 在 ThoughtWorks 工作,因此我们询问了有关 JRuby 和 DSL 的发展动向:
毫无疑问,这些都在 SWTBot 的日程表上。SWTBot 仍然缺少大量 API,我们正在原来的基础上不断进步。SWTBot 的大部分功能都是基于 Twist 开发团队的需求、反馈和 SWTBot 社区。目前还没有真正需要集成 JRuby 的理由。我相信这是因为没有太多人使用 JRuby 开发 SWT/Eclipse。所以,JRuby 集成目前还不在考虑中。
SWTBot 2.0(目前是 beta 版)组合了 FluentInterface 和微型的 DSL 来查询 widgets。我认为这是一种不断发展和提供足够句法支持而不使用完全 JRuby 方式的好办法。
SWTBot 也提供了一个录制器,目前它处在什么状态呢?
录制器只是为了体现概念而开发,所有没有投放太多的精力在上面。它对大多数控件都不支持,也不会录制所有操作,虽然添加这些支持很简单。录制器采用中间格式录制代码,类似于抽象语法树。这种表示随后会输出成你选择的语言,目前它支持 Java,但 Ruby 也是可以的。
还要注意:录制和回放不是编写测试的推荐方式(参见 TestingGUIApplications 和录制 vs. 编码)。这主要是因为一个工作流(或者所有脚本)的完整脚本在被测应用发生微小改动之后需要重新录制。SWTBot 提倡采用 PageObject/ScreenObject 模式(或参见重用功能性测试)。
那么,未来有什么规划?
SWTBot 对于参与其中的每一个人来说在很多方面都是一个学习的历程。SWTBot 目前在进行第三次重写。我们在 2.0 版中改正了 1.x 版的很多错误。
我们移除了 Java 1.4 代码库以便使用 Java 1.5 的新功能,特别是泛型。我们也分解了 SWTBot 的一些子系统。这使得 SWTBot 更具扩展性,能够支持多页面编辑器、Eclipse 富表单编辑器和 GEF。
同时,申请把 SWTBot 移到 eclipse.org ,这可以方便更多用户访问 SWTBot,使所有人受益。
一些有关使用 SWTBot 测试的好技巧可以浏览 David Green 的博客文章“"Eclipse GUI Testing Is Viable With SWTBot ”。
Marathon
与 SWTBot 相反, Marathon 可以用于测试 Swing 应用。 Marathon 带有自己的编辑器和测试运行器,也支持调试和提供 Ant 任务。 Marathon 由 Bangalore 的 Jalian Systems 公司开发,基于 GNU LGPL 协议。我们采访了 Marathon 的主要维护者和开发人员 Dakshinamurthy Karra。
相比 SWT,已经有太多测试 Swing 应用的工具,所以我们询问是否计划支持 WST:
我们计划发布一个基于 Eclipse 的商业版本。由于各种原因推迟了。我们希望在未来几个月能够发布。作为一个团队,我们目前关注的是添加对 Web 测试的支持。根据需求的不同,我们随时准备添加对 SWT 的支持。但目前我们收到了更多支持 Web 应用的要求。
Marathon 支持 JRuby 和 Jython,为什么选择这两种语言?
Jython 是初期开发人员选择的语言。我们个人喜欢 Ruby,所以添加了对 JRuby 的支持。Marathon 架构支持插件式脚本模型。JVM 支持的任何语言(Groovy,Bean shell,Clojure)都可以被添加进去。
另一个偏爱 Ruby 的原因是可以创建 DSL。而且还计划(仍在萌芽阶段)添加基于关键字的测试。
我们非常乐于看到社区能贡献出针对其他语言的支持。
看到 Marathon 的屏幕截图,感觉界面类似于 Eclipse,其中有什么联系吗?
我们正准备发布一个基于 Eclipse 的商业版本(暂定名 MarathonITE——Marathon 集成测试环境)。Eclipse 是我们的开发平台,这是 UI 类似 Eclipse 的一个原因。当我们需要实现一个功能的时候——我们通常会看看 eclipse 是如何实现的。
没有计划把 Marathon(开源版本)集成到某 IDE。
使用 JRuby(或者 Jython)测试是把动态语言偷偷用在传统开发环境的一个好机会。
你又是如何创建 UI 测试的呢?
查看英文原文: Java GUI Testing With JRuby
评论